How to change the replication group information after db files are created

Question

Since group information is persisted in the database, I am wondering if there is a way to update the information.
We want to implement some kind of Berkeley DB master relay mechanism for our two data centers, which has slow link in between. Basically have one master populating a database file and launch another two node as master to replay that to other nodes of its own group. It will be much efficient this way so we don't have to copy the data multiple times over the slow link.
We periodically (once a day) update the Berkeley DB content from customer's feed on a backend node and upload (rsync) the Berkeley DB File to two the data centers. We would like to have a master node in each data center to read the pre-populated data file, replicate the changes to the web node (read only) while they are still running. I simulated local and if I trick the nodeName and nodeHostPort setting, it should work (basically, fake the replication node on the backend node using tampered hostfile so they get registerred). However, it is not very convenient and definitely a dangerous hack on the production servers.
If there is a way, after the creation, to update the group information (for example, change all the nodes information) without corrupt the log file/replication stream, it will be much easier for us. Basically, we would like to have the node/group information and data file de-coupled?
Any ideas how to do that, or is there a better way to design such a replay of data using Berkeley DB?
Thanks in advance!

Answer 1

2. You mentioned to not clean up the log file. Is there a point where I can safely call clean up on the environment when BDB is still online as I can imagine we will run out of space very soon if we don't clean up.The approach outlined above (steps 1 to 5) will ensure that no log files are deleted on A while you are updating B and C. The use of DbBackup ensures this. For more information on how this works, see the DbBackup javadoc.
Whether this causes you to run out of disk space on A is something you'll have to evaluate for yourself. It depends on the write rate on A and how long it takes to do the copy to B and C. If this is a problem, you could make a quick local copy of the environment on A, and then transfer that copy to B/C. But you must prohibit log file deletion during the copy, using DbBackup, or the copy will be invalid.
You should perform explicit JE log cleaning (including a checkpoint) before doing the copy to B/C. This will reduce the number of files that are copied to B/C, and will reduce the likelihood that you'll fill the disk on A. See the javadoc for Environment.cleanLog for details on how to do an explicit log cleaning.
In your earlier post, it sounded like the updates to A were in batch mode -- done all at once at a specific time of day. If so, you can do the copy to B/C after the update to A. In that case, I don't understand why you are afraid of filling the disk on A, since updates would not be occurring during the copy to B/C.
--mark