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

nbackup unlock causes internal Firebird consistency check (next transaction older than oldest active transaction) [CORE6059] #6309

Closed
firebird-automations opened this issue May 2, 2019 · 3 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Omacht András (aomacht)

Hi!

Our backup script uses nbackup.
1. It locks the database with -L
2. Copy it (with scp) to an another box
3. Unlock with -N

We have running and newly starting transactions while the backup process running.

Backup log:
2019-04-30 23:19:56 /u1/firebird/database.fdb LOCKED [ OK ]
2019-04-30 23:20:00 /u1/firebird/database.fdb SCP[ OK ]
2019-04-30 23:20:00 /u1/firebird/database.fdb UnLOCKED [ OK ]

Firebird log (same time as unlock):
server<--->Tue Apr 30 23:20:00 2019
<------>Database: /u1/firebird/database.fdb
<------>internal Firebird consistency check (next transaction older than oldest active transaction (266), file: cch.cpp line: 6523)

server<--->Tue Apr 30 23:22:01 2019 (2 mins later!)
<------>Database: /u1/firebird/database.fdb
<------>deadlock

We have 3 other databases following with the same error (internal Firebird consistency check (next transaction older than oldest active transaction (266), file: cch.cpp line: 6523)).
But only 2 of 4 have deadlock entry.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Few questions:

What architecture is used (SS\CS\SC) ?
Does "3 other databases" served by the same Firebird host\instance ?
How long you using this way of backup ?
How often it happens ?
How to reproduce it ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Omacht András (aomacht)

Hi Vlad!
Classic architecture.
All databases served by the same instance (we have other instances too, but this dbs have the same).
We've been using nbackup at least two years. (Switched from gbak.)
It happens first time.
We try to reproduce it, if it succeeds, I describe the way.

@omachtandras
Copy link

We cannot reproduce the issue since then, so Vlad, please close it. Thanks!

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

3 participants