> So does this mean that if it's unable to replicate after some number of > sleeps, > as the ones you've listed above, it gives up trying to replicate?
No, it continues to sleep for 10 seconds forever (until it can replicate). > OK. So sequentially restarting each RS on the master cluster should be OK and > the replication will/should continue where it left off? I prefer bouncing the whole cluster at the same time because of HBASE-3441. > Right, right... http://blog.sematext.com/2011/03/11/hbase-backup-options/ > OK, so if we have a *live* cluster and then one day we decide we want to start > replicating this cluster, we need to stop the cluster first, call CopyTable > for > each table, start the slave cluster, restart the master cluster, and > replication > should kick in and keep the 2 clusters in sync. No: 1 - Have replication enabled on the cluster. 2 - Start the replication to a slave. 3 - Make down the current timestamp. 4 - Start the copy table job with the upper timestamp to the one you just got (meaning that all the data until that moment will be copied while new data is already replicated). 5 - Repeat for every table with the same upper ts. My prod cluster has only 1 map slot so that jobs, including CopyTable, don't kill the performance. > And then if the slave cluster goes down for a while one day, replication won't > be sufficient - one will need to repeat the above procedure again, right? No, the master won't delete hlogs that are still due to be replicated. > > Aha, thanks for pointing it out. > This also means that one should really be using the latest and greatest about > to > be released HBase in order to get this fix, which is good to know. Yeah... our setup here always lags when it comes to upgrading so some stuff that's well tested in a previous version may be broken in a newer one until we start deploying it and figure it out. As the project moves on, I hope that more users and more developers will help solve this issue as we only have so many cycles. J-D
