maria-developers team mailing list archive

[Jeremy Zawodny <Jeremy@xxxxxxxxxxx>]

If the connection between a slave and master is interrupted, the slave won't
report itself as being "behind" until the slave's network timeout to the
master expires and it reconnect (assuming it can).

Jeremy

On Mon, Jan 25, 2010 at 10:44 AM, <seppo.jaakola@xxxxxxxxxxxxx> wrote:

> Hi Jeremy,
>
> Thanks for the input. I'm not sure what you mean with true replication
> latency here.
> Anyway, the replication system can internally measure latencies
> from the point where the replication event was passed for replication
> until it was received/applied in the receiving end. And these latency
> measurements can be averaged and visualized for end user .e.g. through
> status variables.
>
> Or is there something more you are looking for...?
>
> Cheers, Seppo
>
> --
> http://www.codership.com  seppo.jaakola@xxxxxxxxxxxxx
> skype: seppo_jaakola
>
>
> Quoting 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>
>>> <https://launchpad.net/%7Emaria-developers>
>>>
>>> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~maria-developers<https://launchpad.net/%7Emaria-developers>
>>> <https://launchpad.net/%7Emaria-developers>
>>>
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
>
> _______________________________________________
> 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
>