state error of segment (asynchronous replication)

[Georg Pfolz]

After setting up asynchronous replication, the segment files are copied to the correct journal_source_directory, where they disappears after a few seconds. But the data are not applied to the replica database.

I get this kind of message in the replication.log file:

VERBOSE: Deleting file (/mnt/server1/archive/mydb/mydb.fdb.journal-000000133) due to incorrect state (expected either FULL or ARCH, found FREE)

What does it mean and what can I do about it?

[Dmitry Yemanov]

Something is seriously wrong. I've never heard of such an issue before.
Could you please show your replication.conf from the master side?


Dmitry

[Georg Pfolz]

Here is my replication.conf on the master side:

database = /path/to/dbdata/db.fdb
{
verbose_logging = true
journal_directory = /path/to/dbdata/journal/db
journal_archive_directory = /path/to/dbdata/archive/db
journal_archive_command = "test ! -f $(archivepathname) && cp $(pathname) $(archivepathname) && cp $(pathname) /usr/local/shared/db_archive_server1/db/ && mv $(pathname) /usr/local/shared/db_archive_server2/db/"
journal_archive_timeout = 10
}

[Georg Pfolz]

I got it working! Your request for the master's replication.conf put me on the right track: it was the mv command to the shared directory accessed by server2 that caused the trouble. I still don't understand why that's the case, but after I rearranged the commands, it started working as expected on server2 (which was the one throwing the errors, I didn't test server1 but I guess I would have been fine).

journal_archive_command = "test ! -f $(archivepathname)  && cp $(pathname) /usr/local/shared/db_archive_server1/db/ && cp $(pathname) /usr/local/shared/db_archive_server2/db/ && mv $(pathname) $(archivepathname)"

Now the files actually used for replication are copied with the cp command and the last command moves the segment to the archive directory which has no other purpose than to archive them (not sure if that's necessary, I guess I could as well just delete the segment, can I?). 

Or maybe, if I want to archive them properly, I should mv $(pathname) $(archivepathname)&& rm ${pathname} (otherwise if ever I wanted to use those archived segments, they would produce the state error).

By the way, thanks for the quick answers, even to dumb questions, this is of tremendous help for a Firebird newbie such as myself!

[Georg Pfolz]

My final journal_archive_command:

journal_archive_command = "test ! -f $(archivepathname)  && cp $(pathname) $(archivepathname) && cp $(archivepathname) /usr/local/shared/db_archive_server1/db/ && cp $(archivepathname) /usr/local/shared/db_archive_server2/db/ "

My problems came from the wrong assumption that the journal_archive_command has to take care of the moving or removing of the file. Other than the strange error above, it caused every second segment to disappear. After monitoring the journal_directory, I realised that Firebird takes care of it and trying to do it oneself interferes with the replication mechanism.