Architecture of Replication
[[Category:MySQLUniversity]
- Presenter: Lars Thalmann
- Time: Thursday 8. March 2007, at 6am PST = 9am EST = 15 CET = 16 EET
- Time (at the Heidelberg Developers Meeting): Thursday, September 20, 15:00 CET
- Scribe: MC Brown
- Scribe (at the Heidelberg Developers Meeting): Paul DuBois
Attendees: To register for this Session - Please enter your name here: Alexander Nozdrin Andrey Hristov Marc Alff Martin MC Brown Sergei Golubchik Ingo Strüwing Giuseppe Maxia Stefan Hinz Dmitri Lenev Chris Powers Omer BarNir IgnacioGalarza Timour Jeffrey Pugh User:TimSmith Jimmy Guerrero Paul DuBois Damien Katz Max Mether Chuck Bell GeorgiKodinov Susann Wolfgram
[edit] Architecture_of_Replication
[edit] Comments During Heidelberg Presentation
Q: re: Pushing the transaction cache. The cached information is exactly what gets written to the binary log?
- Yes.
Q: So wouldn't that allow multiple writers to write to the binary log, rather than the current implementation of allowing a single writer? Or something like group commit if there are multiple transactions ready to be written?
- Conceptually, it should be possible.
Transactions consisting of modifications to non-transactional and transactional statements are difficult to replicate in the event of rollback or failure. Modifications to non-transactional tables are written directly to the binary log if they appear before the first modification to a transactional table, so rollback will not cancel those non-transactional modifications for slaves. But different scenarios have different effects, and there is not necessarily a "correct" solution in some instances. This is an open problem that deserves further work.
Q: There is a single thread handling communication between the master and a slave. Would it be possible to use multiple streams?
- There are plans for multi-source replication. The principle is to allow a given slave to accept input from multiple masters, but by having all streams come from the same master, it would achieve multiple-stream input from a given master.
One negative of multi-source: Multiple copies of the binlog will be sent to the slave. Some kind of filtering is needed.
Q: Why would an error ever need to be replicated?
- Because it might have side-effects that must be replicated.
Q: What if a slave table has a column that the master table does not?
- The extra column on the slave is assigned its default value.
Q: What if a column on the slave has a different type than in the master table?
- Some types can be auto-converted to other types. If so, that is done. If not, the SQL thread stops.