Issue Details (XML | Word | Printable)

Key: CORE-6059
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Omacht András
Votes: 0
Watchers: 6
Operations

If you were logged in you would be able to see more operations.
Firebird Core

nbackup unlock causes internal Firebird consistency check (next transaction older than oldest active transaction)

Created: 02/May/19 10:09 AM   Updated: 02/May/19 10:38 AM
Component/s: Engine, NBACKUP
Affects Version/s: 2.5.8
Fix Version/s: None

Environment:
Linux 4.1.12-124.25.1.el7uek.x86_64 #2 SMP x86_64 x86_64 x86_64 GNU/Linux

QA Status: No test


 Description  « Hide
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.




 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 02/May/19 10:28 AM
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 ?

Omacht András added a comment - 02/May/19 10:38 AM
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.