RATIONALE --------- The replication code is integrated with the server. This work is to have it as separate modules to make it easier to maintain and to make it possible to release updates more often than the server. SOLUTION -------- The two solutions are to make it either a static module, or a dynamically loadable module. 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. USE CASES --------- 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? REFERENCES ---------- See also WL#5377
We are planning to create a set of sub tasks to handle this big work. The first sub task will be refactoring the replication code into separate libraries, which will be handled by WL#5385. Other tasks will be created and handled later.