Unreliable replication behaviour in Linux Classic

[grzegorzzyla]

Replication always stops on the same segment.
The only error in the log is that the process has stopped.
Every restart ends the same.
OS: CentOS 8 Stream.
FB mode: classic.

SRV-01-SI-4-REP (replica) Wed Nov  2 10:56:02 2022
        Database: /db-zpue/db/si.fdb
        VERBOSE: Segment 743 (34832 bytes) is replicated in 0 ms, preserving the file due to 1 active transaction(s) (oldest: 204980332 in segment 731)

SRV-01-SI-4-REP (replica) Wed Nov  2 10:56:02 2022
        Database: /db-zpue/db/si.fdb
        VERBOSE: Segment 744 (47351 bytes) is replicated in 0 ms, preserving the file due to 1 active transaction(s) (oldest: 204980332 in segment 731)

SRV-01-SI-4-REP (replica) Wed Nov  2 10:56:02 2022
        Database: /db-zpue/db/si.fdb
        VERBOSE: Segment 745 (53729 bytes) is replicated in 0 ms, preserving the file due to 1 active transaction(s) (oldest: 204980332 in segment 731)

SRV-01-SI-4-REP (replica) Wed Nov  2 10:56:24 2022
        Database: /db-zpue/db/si.fdb
        ERROR: connection shutdown
        Engine is shutdown.
        At segment 746, offset 22884

SRV-01-SI-4-REP (replica) Wed Nov  2 10:56:24 2022
        Database: /db-zpue/db/si.fdb
        VERBOSE: Suspending for 60 seconds

SRV-01-SI-4-REP (replica) Wed Nov  2 10:57:01 2022
        Database: /db-zpue/db/si.fdb
        VERBOSE: Started replication thread

SRV-01-SI-4-REP (replica) Wed Nov  2 10:57:01 2022
        Database: /db-zpue/db/si.fdb
        VERBOSE: Added 8188 segment(s) to the processing queue

[dyemanov]

The question is why server process has unexpectedly stopped.

[grzegorzzyla]

I don't know it yet but will compile the debug version of the server, maybe it will do some core dump.

[grzegorzzyla]

ok, starting this replication, I noticed that the process starts only when there is a connection to the database. So I made a cron script that connects and disconnects after some time. It turned out that for this larger data packet this time is too short, hence in the log, after disconnecting the user, there is a record that the replication process is also ending.
2022-12-07T12:30:24.5430 (1666781:0x7f357c71d040) ERROR AT JReplicator::process
/db-zpue/db/si.fdb (ATT_343679, SYSDBA:NONE, NONE, )
335544856 : connection shutdown
335545133 : Engine is shutdown.

Does the user really have to be logged in to the slave database for replication to work?

[dyemanov]

If Firebird server is launched by the TCP daemon (xinetd or alike), then it's expected. The process is not loaded without user connections and thus cannot perform replication. However, this is weird, as FB v4 should use its own TCP listener rather than xinetd. But you can solve it by switching to SuperClassic instead of Classic.

[grzegorzzyla]

In SuperClassic I have a different problem, not in replica but in production where the server crashes
/usr/local/firebird/bin/fbguard: /usr/local/firebird/bin/firebird terminated abnormally (-1)

[dyemanov]

What's a problem to use Classic in production and SuperClassic for replica?

[grzegorzzyla]

The problem is that I want to use SuperClassic in production :)
I will run the debug version in production and see if I can get a coredump for analysis.