I guess it would come down to the ability to dump the data at a regular interval, and the speed at which it can be transported. Does the DB need to be in a shut down state to replicate? I would be interested in what info you have found regarding it.
I like the idea of a way to invoke a citadel to be a standby, as long as it can drop out of standby mode and start up as a server without some long process of shutting down first. Also, I use something similar right now for replicating my data. I have /usr/local/citadel in a zfs backed partition, which I replicate through zfs send / receive on a remote server. So my data is in general not more than a minute old, but it is all manually hacked together and neither server knows if it is still supposed to be running and such. It would be beneficial for the master / replication slave to have a pull method (then you are not bogging down the master with trying to figure out who needs a copy of the data and you can have multiple geo distinct locations pulling a copy to potentially be the master. This would deal with firewall issues in general, as the command can be sent through the existing command interface. I could go on, but would like to know if this is a productive line of thought. It would be REALLY helpful to many of us to make this happen. > Thu Jul 13 2017 12:51:37 PM EDT from IGnatius T Foobar @ Uncensored >Subject: Re: Crowdsourced Testing... > > >>I am facing it currently as I need two machines running in sync with each > > >>other as failover (my situation is similar to what harryc described in the > > >>twin towers discussion last year). A Master slave situation would be fine, > as > >This is one of the many reasons I am gradually moving everything into the >database. We're very close to achieving that objective. > >Once everything is in the database, replicating the database will replicate >the entire Citadel environment. Even at the current stage, you'll get >everything except for file libraries (which will probably never go into the >db, but few sites even use that function), a couple of system messages, and >the server's SSL keys. I replicate my site using a "snap-and-ship" method, >with btrfs snapshots followed by rsync, but in the future we could experiment >with Berkeley DB's own replication functions. My understanding is that they >provide the data source and sink, and you have to provide the transport. >Perhaps we would invoke citserver with a command-line option that tells it >"don't be a Citadel server today; just connect to the master and replicate." > > > >
