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
