I run a medical office and have been very happy with GT.M and now ydb for many years.
Our current backup solution is to turn our server machine (actually it is a VM) every night and perform a cold backup. I would like to enhance this to using database replication which would reduce our need to do this. I will probably still back up the entire machine once a week, or perhaps once a month, but with continuous replication it would be much better overall.
Why now? Well, my home now has a static IP address, which makes the networking easier. Also, I have changed our office router/firewall from an ancient (2016) Cisco ASA 5505 to an OPNsense network appliance which has enabled me to safely make the IP of the home backup server easily reachable, while still maintaining encrypting and data safety. So all the pieces are in place now, and I want to try setting up replication.
The first thing the documentation does it dive right into the deep end talking about the underlying technology of journal entries. Apparently there database transaction numbers, journal sequence numbers, and stream sequence numbers, and it is apparently very important to understand these, how they differ, and what the status of the source and the replicating database are in relation to these numbers. And everything is apparently coordinated by an "instance file". But the first time in the text that it is mentioned, it is just thrown in casually as if the user already knows all about instance files. And apparently I am also supposed to be very comfortable with MUPIP and feel comfortable that changes I make there won't mess up my database.
It seems that this documentation is more of a technical guide rather than a user's guide on how to get started. There are examples later down the pate, but they are prefixed with this scary warning: "These example scripts are for explanatory purposes and are not intended
for production use. YOU MUST UNDERSTAND AND APPROPRIATELY ADJUST THE
COMMANDS GIVEN IN THESE SCRIPTS BEFORE USING THEM IN A PRODUCTION
ENVIRONMENT." This is, of course, always good advice. But it doesn't fill me with confidence in my ability to achieve a solution.
My goals:
1. Set up replication from server (A) to backup-server (B)
2. When A needs to go down for maintenance or backup, then part of the shut-down script will make all the needed changes such that B becomes the primary server. In the documentation, this is discussed under the name "switchover."
3. When A comes back up, part of the startup script would tell B it was ready to take over. So it would catch up on transactions that B would have to send to A. And then B will return to recipient mode. I think this is all standard stuff.
Because we use VistA and CPRS, we would need to have each CPRS stop specifying a static ip address and instead get the address of the active server via a local DNS server.
Questions:
-- Should I just suck it up and try harder reading the linked-to documentation?
-- Are there other resources that are less "expert-friendly"?
-- Anyone out there interested in submitting a proposal to set this up for me, for pay?
Thanks
Kevin