Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect shutdown, when database is in phisical backup mode [CORE943] #1344

Closed
firebird-automations opened this issue Sep 27, 2006 · 17 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Yakov Hrebtov (jake)

If database is in phisical backup mode, then it cannot be properly shutdowned.
No errors are reported and new connections allowed after shutdown.

Steps to reproduce:
1. Put database in phisical backup mode:
/opt/firebird/bin/nbackup -L mydb
(it can be a real backup command, not just DB lock)
2. Shutdown database:
/opt/firebird/bin/gfix -shut single -force 0 mydb
(No errors are reported here!)
3. Check that new connections are still allowed.

Commits: 05473ab dd0931d 85aa6f1 915e919 c906e4d a064dc6

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 2.0.1 [ 10090 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Question:

If the above sequence works as expected and doesn't allow new connections, would you consider okay that the following operation:
/opt/firebird/bin/nbackup -N mydb
will throw an error: "database is shutdown"? Of course, the following sequence:
/opt/firebird/bin/gfix -online mydb
/opt/firebird/bin/nbackup -N mydb
will work fine.

@firebird-automations
Copy link
Collaborator Author

Commented by: Yakov Hrebtov (jake)

What is going to happen if database shuted down during real nbackup -B command? What if nbackup finishes (and should unlock database), but database is in shutdown mode?
IMHO, throing error in this case is impossible... Will nbackup wait for online, and then unlock DB?

@firebird-automations
Copy link
Collaborator Author

Commented by: Yakov Hrebtov (jake)

Of course, waiting for online is bad thing too.
In any case, seems to me, that nbackup/shutdown behavior proposed by Dmitry will force us to write rather complex scripts to surely automate nbackup.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I'm wondering why you would need a shutdown in order to perform a physical backup?

@firebird-automations
Copy link
Collaborator Author

Commented by: Yakov Hrebtov (jake)

It seems, you missunderstood me (or I'm missunderstanding you :).
Nbackup is intended to be automated (scheduled), shutdown is almost manual thing. And they can intersect in time.

Consider the following sequence:
1. Hourly scheduled incremental backup starts (nbackup is locking database and begins to do backup).
2. Database administrator manualy shuting down database in order to update metadata (he is didn't know that database is in phisical backup now).
Admin begins to work with database in exclusive mode.
3. nbackup (started in step1) completes its work and trying to unkock database.
4. Admin finishes and putting DB online.

As I understand your initial question, you asking about throwing error on step 3 in this sequence.
If so, database remains locked after step 3.
I'm talking about this is not very good, because we have to care about unlocking database after step 4 and before next hourly nbackup.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1 [ 10041 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pcisar

Dmitry, can you please comment on how this issue was fixed (i.e. the new behaviour)? There is no clear resolution in current comments and I really don't want to decode it from code changes :) It's necessary to verify the fix and for inclusion into documentation.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

It has been discussed in fb-devel. The new behavior is:
- Multi-user shutdown mode is allowed for a physically locked database and it's respected by the server
- Single-user and exclusive shutdown modes cannot be set for a physically locked database (error is thrown)

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pcisar

Reopened to update ticket information.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Closed [ 6 ] => Reopened [ 4 ]

resolution: Fixed [ 1 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Fix Version: 2.1 Alpha 1 [ 10150 ]

Fix Version: 2.1.0 [ 10041 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Reopened [ 4 ] => Closed [ 6 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11225 ] => Firebird [ 15297 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants