maria-developers team mailing list archive

[worklog-noreply@xxxxxxxxxxxx]

-----------------------------------------------------------------------
                              WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...........: Multi-source replication
CREATION DATE..: Thu, 23 Jun 2011, 12:50
SUPERVISOR.....: 
IMPLEMENTOR....: 
COPIES TO......: 
CATEGORY.......: Server-RawIdeaBin
TASK ID........: 201 (http://askmonty.org/worklog/?tid=201)
VERSION........: Server-9.x
STATUS.........: Un-Assigned
PRIORITY.......: 60
WORKED HOURS...: 0
ESTIMATE.......: 0 (hours remain)
ORIG. ESTIMATE.: 0

PROGRESS NOTES:



DESCRIPTION:

This worklog is about implementing a way for a MariaDB replication slave to
replicate from more than one master simultaneously.

Each master is handled by a specific replicator instance in the slave
server. Each replicator instance consists of separate I/O thread, SQL thread,
and associated state and configuration. In efffect, several replication slaves
are running at the same time, each replicating from a separate master, but all
replicating into a common data store (typically, but not necessarily to
separate databases/tables).

A replicator instance is identified with a user-chosen name used in
replication SQL statements such as CHANGE MASTER TO ...
This name is also included in file names to distinguish the files that keep
the replication state (relay logs, master.info, relay-log.info).  This way,
each separate instance can be configured separately, but otherwise the same
way as existing single-source replication.

In order to remain backwards-compatible with existing third-party scripts
etc., the replicator instance name is made optional in all existing
replication statements. If it is omitted, the name "default" is used, and for
this particular name, master.info and the other files retain their old names
to allow seamless upgrades of slaves.

In this worklog, there is no extra conflict resolution proposed. The effect of
updates from one master on replication from another master will be the same as
the effect of direct user SQL queries on the slave server, ie. it is the
responsibility of the user/DBA to ensure no conflicts occur. If a conflict
causes replication of an event to fail (with duplicate key violation eg.), the
corresponding slave SQL thread will stop, requiring manual intervention to fix
and start.

An easy and typical way to avoid conflicts would be to eg. to use separate
databases for each master->slave replication channel. RBR idempotent slave
application can also be used to help resolve conflicts, for example.

See also MySQL WL#1697: http://forge.mysql.com/worklog/task.php?id=1697


ESTIMATED WORK TIME

ESTIMATED COMPLETION DATE
-----------------------------------------------------------------------
WorkLog (v4.0.0)