JD, thanks. I agree with you. the current replication mechanism will handle such situation exactly as you suggested. Were I the DBA, I will focus on restart my Master-cluster instead of shipping the delta over to slave-cluster.
However, my customer still would like to have the tool to sync-up the data in the case of Master down. I guess the reasons are not purely from technical perspective, more for a business check mark. :-( that is why I am looking for a way. Can you please give me some pointers to start with? many thanks Demai On Fri, Jul 26, 2013 at 10:08 AM, Jean-Daniel Cryans <[email protected]>wrote: > As soon as you restart your master, it will continue replicating from > where it was, so it will send that delta. > > J-D > > On Mon, Jul 22, 2013 at 4:42 PM, Demai Ni <[email protected]> wrote: > > hi, folks, > > > > I am trying to address a recovery scenario after Master crash. > > > > In a simple Master - Slave replication setup for t1, and suddenly Master > > crashes. there will be a small delta of t1 already changed on Master, but > > haven't been replicated to Slave yet. Assuming Master's filesystem and > > network still available, how to apply the delta from Master to Slave to > > sync t1. > > > > Anyone addresses this scenario in your shop? Can you please give me some > > pointers? > > > > Basically, I need to address two things: > > 1) get the timestamp of last consistent point of T1. some thing like > > oldest(lastAppliedOP_of_T1 of each regionServer on Slave Cluster). Any > > other way to do so? > > > > 2) something like copyTable utility with starttime from 1). However > > copyTable requests hbase and zookeep available from source > cluster(right?) > > > > > > I have been thinking about ways to address this for quite a few days and > > still don't have very good ideas yet. Any suggestion is greatly > appreciated > > > > thanks. > > > > Demai >
