maria-developers team mailing list archive
Mailing list archive
Re: Ideas for improving MariaDB/MySQL replication
+1 on a replication heartbeat w/configurable heartbeat time. We'd want to
issue a heartbeat pules every 1 sec in our environment to measure *true*
On Fri, Jan 22, 2010 at 6:21 AM, Kristian Nielsen
> The three companies Continuent, Codership, and Monty Program are planning
> start working on some enhancements to the replication system in MariaDB,
> together with anyone interested in joining in.
> At this stage, there are no fixed directions for the project, and to do
> in as open a way possible with the maximum community involvement and
> we agreed to start with an email discussion on the maria-developers@mailing
> list. So consider it started!
> The plan so far is:
> 1) The parties taking this initiative, MP, Continuent, and Codership,
> their own ideas in this thread on maria-developers@ (and everyone else who
> wants to chime in at this stage).
> 2) Once we have some concrete suggestions as a starting point, we use this
> reach out in a broader way with some blog posts on planetmysql /
> to encourage further input and discussions for possible directions of the
> project. Eventually we want to end up with a list of the most important
> and a possible roadmap for replication enhancements.
> (It is best to have something concrete as a basis of a broad community
> To start of, here are some points of interest that I collected. Everyone
> please chime in with your own additional points, as well as comments and
> further details on these one.
> Three areas in particular seem to be of high interest in the community
> currently (not excluding any other areas):
> - High Availability
> * Most seems to focus on building HA solutions on top of MySQL
> replication, eg. MMM and Tungsten.
> * For this project, seems mainly to be to implement improvements to
> replication that help facilitate improving these on-top HA solutions.
> * Tools to automate (or help automate) failover from a master.
> * Better facilities to do initial setup of new slave without downtime,
> re-sync of an old master or slave that has been outside of the
> replication topology for some period of time.
> - Performance, especially scalability
> * Multi-threaded slave SQL thread.
> * Store the binlog inside a transactional engine (eg. InnoDB) to reduce
> I/O, solve problems like group commit, and simplify crash recovery.
> - More pluggable replication
> * Make the replication code and APIs be more suitable for people to
> extra functionality into or on top of the stock MySQL replication.
> * Better documentation of C++ APIs and binlog format.
> * Adding extra information to binlog that can be useful for non-standard
> replication stuff. For example column names (for RBR), checksums.
> * Refactoring the server code to be more modular with APIs more suitable
> for external usage.
> * Add support for replication plugins, types to be determined. For
> binlog filtering plugins?
> It is also very important to consider the work that the replication team at
> MySQL is doing (and has done). I found a good deal of interesting
> about this here:
> This describes a number of 6.0/5.4 and preview features that we could merge
> and/or contribute to. Here are the highlights that I found:
> - Features included in 6.0/5.4 (which are cancelled I think, but
> this will go in a milestone release):
> * CHANGE MASTER ... IGNORE_SERVER_IDS for better support of circular
> * Replication heartbeat.
> * sync_relay_log_info, sync_master_info, sync_relay_log,
> for crash recovery on slave.
> * Binlog Performance Optimization (lock contention improvement).
> * Semi-synchronous Replication, with Pluggable Replication Architecture.
> - Feature previews:
> * Parallel slave application: WL#4648
> * Time-delayed replication: WL#344
> * Scriptable Replication: WL#4008
> * Synchronous Replication.
> Drizzle is also doing work on a new replication system. I read through the
> series of blog posts that Jay Pipes wrote on this subject. They mostly deal
> with how this is designed in terms of the Drizzle server code, and is low
> detail about how the replication will actually work (the only thing I could
> really extract was that it is a form of row-based replication). If someone
> links to information about this that I missed, it could be interesting.
> Let the discussion begin!
> - Kristian.
> Mailing list: https://launchpad.net/~maria-developers<https://launchpad.net/%7Emaria-developers>
> Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers<https://launchpad.net/%7Emaria-developers>
> More help : https://help.launchpad.net/ListHelp