maria-developers team mailing list archive

[Jeremy Zawodny <Jeremy@xxxxxxxxxxx>]

+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*
replication latency.

Jeremy

On Fri, Jan 22, 2010 at 6:21 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx>wrote:

> The three companies Continuent, Codership, and Monty Program are planning
> to
> 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
> this
> in as open a way possible with the maximum community involvement and
> interest,
> 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,
> present
> 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
> to
> reach out in a broader way with some blog posts on planetmysql /
> planetmariadb
> 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
> goals
> and a possible roadmap for replication enhancements.
>
> (It is best to have something concrete as a basis of a broad community
> discussion/process).
>
> 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,
> or
>      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
> build
>      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
> example
>      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
> information
> about this here:
>
>
> http://forge.mysql.com/wiki/MySQL_Replication:_Walk-through_of_the_new_5.1_and_6.0_features
> )
>
> 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
> presumably
>   this will go in a milestone release):
>    * CHANGE MASTER ... IGNORE_SERVER_IDS for better support of circular
>      replication.
>    * Replication heartbeat.
>    * sync_relay_log_info, sync_master_info, sync_relay_log,
> relay_log_recovery
>      for crash recovery on slave.
>    * Binlog Performance Optimization (lock contention improvement).
>    * Semi-synchronous Replication, with Pluggable Replication Architecture.
>      http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication
>
>  - Feature previews:
>    * Parallel slave application: WL#4648
>      http://forge.mysql.com/wiki/ReplicationFeatures/ParallelSlave
>    * Time-delayed replication: WL#344
>      http://forge.mysql.com/wiki/ReplicationFeatures/DelayedReplication
>    * Scriptable Replication: WL#4008
>      http://forge.mysql.com/wiki/ReplicationFeatures/ScriptableReplication
>    * 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
> on
> 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
> has
> 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
>