Async HQbird replication
When master and replica are on different machines, archived replication segments must move from master to replica. Two usual paths: HQbird’s built-in FTP (WAN, high latency, different regions) or a network share (fast LAN, 1 Gbit recommended). How to turn replication on: replication setup.
Transfer via embedded HQbird FTP
Best when the link is unstable, high-latency, or geographic. HQbird includes an FTP client and server - no extra tools. Enable Master → Asynchronous; HQbird creates two folders next to the database (${db.path}). Save, then restart the FirebirdHQbird service to start journaling.
Job: Transfer Replication Segments
Watches the archive folder and uploads new segments to a remote FTP (up to five destinations). Types: FTP, FTP over SSL/TLS, FTP over SSH. Enable the embedded FTP server on the replica.
- Check period, seconds - how often to look for new files
- Monitor this folder - default
${db.repparam_log_archive_directory}(LogArch) - Filename template - same macro for the archive name mask
- Age of oldest file to alert (minutes) - default 60; warns if transfer is stuck
- Compress segments - on by default: compress + encrypt before upload
- Failed connection attempts to disable FTP - default 0 = never give up
- How many old (sent) files to keep - default 10, then rotate
- Send Ok report - email on each upload (off by default)
- Name prefix to rename uploaded reinit files - leave for automatic reinit
File Receiver on the replica
Configure Replica → Asynchronous (defaults are filled). Save; restart Firebird (or drop all connections). Then open File Receiver: it watches Monitor directory every Check period, minutes for mask *arch* and extension .replpacked (defaults), decrypts with Decrypt password, and unpacks to Unpack to directory.
- Remove packed files after unpacking - on by default
- Send Ok report - off by default
- Perform fresh unpack - off; turn on after re-init to start from segment 1 (it turns itself off after resetting the counter)
Transfer via network share
Use this on a fast, stable LAN. Put the share (1) on the replica, (2) on the master - recommended - or (3) on a third NAS.
Logs on the replica
Master writes archives onto the replica’s share. If the share dies, replication and then user operations on the master can stop.
Logs on the master
Replica reads the master’s share. If the share dies, the replica pauses applying segments but stays readable; it resumes when the share returns.
Third location
Mix of the two: master still depends on that share being writable.
Recommended: archive locally on the master, share that folder, point the replica at the mount. Master does not depend on the replica’s disk.
Rights
Firebird usually runs as Local System (Windows) or firebird (Linux). On Windows, set the FirebirdHQbird service Log On to an account that can reach the share (for example a domain admin), then restart. Different Windows domains: use FTP instead. On Linux, both firebird users need matching numeric ids on the mount; if that is unfamiliar, use FTP.
For “logs on the replica”, set master’s Log archive directory to the local path of the share and restart Firebird. Replica reads that folder locally. For “logs on the master”, archive locally, share it, replica reads the mount.
Pros: simple on a typical LAN. Cons: needs ~1 Gbit and a stable link; not for WAN; segments travel uncompressed and unencrypted.