MOTIVATION ---------- 1. Long transactions using row-based replication is replicated in-efficiently without this. BACKGROUND ---------- Currently, transactions are grouped together in the binlog. This is expected to cause performance problems with the advent of row-based replication, since the size of a transaction can be much larger. Buffering a huge transaction before writing it to the binlog will cause I/O churn and be bad for performance. The solution is to allow transactions to be interleaved in the binlog. Several proposals for interleaving are currently being discussed on dev-replication@. DESIGN ------ <<Need to be further described>> RELATION TO XA -------------- <<needs to be investigated>> POSITIONING ----------- When transactions are interleaved in the log, we need to know when the first active transaction started, as well as the position we are currently executing. Thus it is not enough to just store the Exec_relay_log_pos in relay_log.info. SERIALIZATION ------------- When the log is interleaved, at some point we need to serialize it. Alternatives: 1. Master Before sending the log to the slave (in COM_BINLOG_DUMP), the log is serialized. 2. IO The IO thread serializes the log before writing the relay log. 3. New serialization thread The new thread reads the relay log and produces a serial log to be read by the SQL thread. 4. SQL The SQL thread starts multiple transactions in parallel corresponding to the interleaved format of the binlog.