SITUATION
---------
Currently, the replication code is an integral part of the server.
PROBLEM
-------
In order to make it easy to develop and deploy special-purpose replication
solutions for both MySQL and for third-party developers, it is necessary to make
the replication code a separate module with well-defined interfaces.
SOLUTION
--------
The two solutions are to make it either a static module, or a dynamically
loadable module (a.k.a. a plug-in). Making it a dynamically loadable module has
several advantages and will still allow the use of the replication module as a
statically linked library, while requiring minor additional work. For that reason,
it makes sense to go for a dynamically loadable module directly.
The following items need to be designed and implemented:
- A handler/handlerton interface to the binary log
- A plug-in interface to the binary log to handle the master side of replication
- A plug-in interface to the server code to handle the slave side of replication
# Example special-purpose solutions
Following are some example solutions that can serve as uses cases.
## Pure row-based replication with side channel for DDL
It is possible to use another transport format than the binary log as we are
using it. For example, it is possible to use a shared disk to handle parts of the
replication, and it could be an advantage to handle the replication of the table
changes using the normal channel, but allow the DDL:s to be executed using a
side channel, such as a shared disk.
## Automatic fail-over replication
In some cases, it might be an advantage to have a separate replication solution
that handles fail over transparantly. Possibly containing customer-specific
solution to detect master failure and finding new masters.
## Group communication protocols for replication
In this case, it is essential to be able to time the execution of the
statements, since replication using group commits delay the execution of
statements to achive a global ordering of the statements. Hence it is not
possible to use a execute-log sequence, but it should rather be a
prepare-execute-log (or prepare-execute-finalize, to be more generic) sequence
to allow the replication machinery to delay the execution of a statement.
# Open issues
We have the following (incomplete) list of open issues:
- The slave side of the code might use threads in an arbitrary manner.
Do we need to refactor the slave thread handling system to allow
arbitrary use of threads? Especially consider the case of dynamically
spawning new threads to parallelize the database update on the slave.
- What use cases do we expect to handle with this worklog?
- Can we use the existing plug-in code, or do we need to extend it?
You must be logged in to tag this worklog