On Mon, 25 Jan 2010 10:47:23 -0800, Jeremy Zawodny
<Jeremy@xxxxxxxxxxx>
wrote:
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
Hi Jeremy,
Does it mean that you want to detect network outages using the
heartbeat?
If so, won't it be easier to just set master-slave connection
timeout to
the desirable value and let replication system to handle it? I'm
asking
this not from position of improving current replication in short
term, but
from position of whether a heartbeat function is needed in
replication API?
Thanks,
Alex
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
--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
