Hello Shawn, Thanks for your comment. It must be helpful.
Moreover, we would like to know; 1. when row-level-replication starts? (every time after issuing SQL statement?) 2. is it "two-phase-commit" or "synchronous" replication? Thanks, Kenji On 9/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Kenji HIROHAMA <[EMAIL PROTECTED]> wrote on 09/08/2005 08:54:58 PM: > > > > Hi, > > Does somebody point me out where I should refer to understand what is > > "row level replication" implemented in 5.1? > > > > I should have read the source comments in the source tree, but the bk > > port is closed at my environment. > > > > Regards, > > Kenji > > > > I couldn't find it in the manual either but I can try to explain the concept > and how it is different than the currently used replication process, > "statement level replication" (SLR). > > If you know how replication currently works in MySQL, you understand that > each SQL statement that makes a change to data (INSERT, UPDATE, or DELETE) > plus several others that modify database structures can be recorded to what > is called the "binary log" or "binlog" for short. I say it as "can be > written" because you can apply some filters so that you only "binlog" the > events that apply to certain tables or datbases that you are interested in > duplicating at the slave server. Events are only written to the binlog as > each transaction is committed, transactions that fail or are rolled back are > not logged in the binlog. Each slave server reads the binlog from the > master, copies it to a local drive, then processes each command in sequence > attempting to duplicate the results that occurred on the Master when it > executed the same statement. Because the slave needs to execute each command > within the exact same set of "enviromental" settings (what time did the > original command occur on the MASTER, within the context of which database, > using which user account, etc.) there are certain problems with duplicating > the effects of particular commands correctly on the slave servers. > > "Row level replication" (RLR) gets around those environmentally-based > pitfalls by actually duplicating each change, row by row, from master to > slave. For statements that change many rows of data, RLR will need a lot of > bandwidth because every change will replicate row-by-row from the master to > the slave. (I don't remember reading if they are optimizing the "difference > stream" by implementing field-level replication or not). This keeps the > slave database in perfect coordination with the master (after some transfer > and processing lag) because stored procedures and other functions that rely > on system- and user-level environmental settings (like time zones) are not > executed on the slave but only on the master. > > Does that help? > > Shawn Green > Database Administrator > Unimin Corporation - Spruce Pine > > > > -- [EMAIL PROTECTED] http://www.hirohama.biz/ Kenji Hirohama -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
