The goal of this worklog is to create uniform interfaces for reading and writing binary log data. This is a step that will allow very simple implementation of the following features: - master with no binary log (for sync or semi-sync replication) and/or slave with no relay log - master uses table for binary log and/or slave uses table for relay log - compress binary log and/or relay log - apply filters at any place in the replication chain (on master before/after writing to binlog, on slave before/after writing to relay log, or in mysqlbinlog) - implement checksums in a much cleaner and efficient way Without this worklog, each of the above features would be big, difficult and error-prone, as the features interact in complicated ways. With this worklog, each feature will be relatively easy to implement and there will be no cross- dependencies between the features. Other similar features are likely to benefit from this worklog in similar ways.
======== BACKGROUND ======== Transactions are read and written in five places: client threads, dump threads, IO thread, SQL thread, and mysqlbinlog. More precisely: - client that is going to write to the binary log "reads" transaction from server (i.e., generates a set of events from the THD object) - client writes to binary log - dump thread reads from binary log - dump thread writes to net - IO thread reads from net - IO thread writes to relay log - SQL thread reads from relay log - SQL thread "writes" to server (i.e., executes event) - mysqlbinlog reads from binary log, relay log, or net - mysqlbinlog "writes" transaction as text Currently, each of these five places has its own ad-hoc code for encoding and decoding transactions, iterate over transactions, retrieve information from transactions, etc. We will propose interfaces that are the same for all "read" operations respectively all "write" operations. ======== PROPOSAL ======== Add two layers: layer 0 and layer 1. -------- Layer 0 -------- In layer 0, a transaction has the form of a 2-tuple: (length, data), where: - length is an integer - data is a sequence of 'length' bytes that contains both transaction data (e.g. the statement) and stream meta-data (e.g., global transaction ID). Layer 0 is used as follows: - The binary log is implemented as a back-end capable of serializing and de- serializing a stream of such tuples on disk. - The relay log uses the same back-end as the binary log, only plugged in at another place in the code. - For the dump thread and IO thread, we implement a 'net' component. The net component is a back-end capable of serializing and de-serializing a stream of 2- tuples to/from a client connection. - Checksumming is trivial to implement as an operation on such 2-tuples. - Compression is trivial to implement as an operation on such 2-tuples. -------- Layer 1 -------- In layer 1, a transaction has the form of a 4-tuple: (length, data, ID, timestamp), where: - length is an integer - data is a sequence of 'length' bytes that contains transaction data (e.g. the statement) - ID is the global transaction identifier for the transaction - timestamp is the time when the transaction was applied on the nearest upstream server (i.e. this server if the tuple appears in a binary log, the master if the tuple appears in a relay log, the slave if the tuple appears in the binary log of the slave, etc) Thus, layer 1 has separated stream meta-data from transaction data. Layer 1 is used as follows: - There will be a canonical way to encode 4-tuples in layer 1 into 2-tuples in layer 0. - The dump thread de-serializes the binary log into layer 0 data; then decodes the data into layer 1 data; then filters out the transactions with IDs that the slave requested not to get; then encodes the remaining transactions into layer 0 data; then serializes them to the net. - The IO thread de-serializes the net into a stream of layer 0 data; then serializes the layer 0 data into the relay log - The SQL thread de-serializes the relay log into layer 0 data; then decodes the data into layer 1 data; then applies the data to the server. - mysqlbinlog de-serializes transactions from the binary log into layer 0; then decodes the data into layer 1; then filters out transactions with IDs or timestamps that should be filtered out according to command-line arguments; then encodes into layer 0; then serializes as text. - To implement binlog-free master, make the dump thread read directly from the server instead of from the binary log (details need to be sorted out carefully here). - To implement relay log-free slave, make the SQL thread read directly from the net instead of from the relay log. ======== Open questions ======== The precise interfaces to read and write to each layer remains to be done. Considerations to take into account: - must support parallel binlog write - must support waiting or not waiting for ack (for sync and semisync to work)