Multi-Master Replication implement

[彭立勋]

We have some requirements of Multi-Master Replication.

For example, we have 100 instances. All of them must have online-backup, if one slave can
only have one master, we must have 100 slave instances to do online-backup.

Our applications will not modified the same rows in different instances, for example,
Instance A have the data of ID in 1~100, Instance B have the data of ID in 101~200, never
conflict.

On the other hand, we can use multi-master do HA in different IDC .For example, We  have
IDC A  And IDC B . The IDC A is dual-master, and IDC B 
is dual-master too. if we have to synchronize data between IDC A   and IDC B , we can 
only use 3rd-party scripts or programs.

       IDC A       |            IDC B
  instance A-1     |       instance B-1
        ^          |             ^
        |          |             |
      VIP<----Scripts----------->VIP
        |          |             |
        V          |             V
  instance A-2     |       instance B-2 
  ( The architecture without Multi-Master Replication)

If we have multi-Master, we can do it like this:
       IDC A      |            IDC B
  instance A-1  <--->   instance B-1
        ^         |             ^
        |         |             |
        |         |             |
        |         |             |
        V         |             V
  instance A-2   <--->   instance B-2 
  ( The architecture with Multi-Master Replication)

my patch usage:

root@localhost : (none) 10:25:54> CHANGE MASTER 'plx2' TO
MASTER_HOST='10.20.147.142',MASTER_PORT=3308,MASTER_USER='test',MASTER_PASSWORD='test',LOG_FILE='mysql-bin.000241',MASTER_LOG_POS=238108499;

root@localhost : (none) 10:25:54> slave 'plx2' start;

root@localhost : (none) 10:25:54> slave 'plx2' stop;

root@localhost : (none) 10:51:47> show slave 'plx1' status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.20.147.142
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.001992
          Read_Master_Log_Pos: 135672840
               Relay_Log_File: mysql-relay-bin-plx1.000012
                Relay_Log_Pos: 8988514
        Relay_Master_Log_File: mysql-bin.001992
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 135672840
              Relay_Log_Space: 8988674
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
1 row in set (0.00 sec)

Attachment is my patch.

This patch implement multi-master by pass different master_info to
change_master/start_slave/stop_slave function.
I implement a class MASTER_INFO_INDEX using which to manage master.info index
file(master.info.index) and a hash table. The correspondence between channel
identification and master_info will store in the hash table and the channel name store in
the index file(master.info.index).
The sake of convenience, I change the syntax of START SLAVE ,  STOP SLAVE ,  CHANGE
MASTER  TO, SHOW SLAVE  STATUS to support channel identification like this: START SLAVE
'channel identification ',  STOP SLAVE 'channel identification',  CHANGE MASTER 'channel
identification' TO, SHOW SLAVE 'channel identification' STATUS .
In CHANGE MASTER situation, mi will create and insert the point into the hash table if
there are no mi correspond to the 'channel identification' in it. otherwise, the point of
mi will get from hash table for operating.

--
Best Wishes

Lixun Peng (P.Linux)

Mobile Phone:
+86 18658156856 (Hangzhou)
Gtalk: penglixun(at)gmail.com
Twitter: http://www.twitter.com/plinux
Blog: http://www.penglixun.com

[Jacky Shu]

I don't think this is a sufficient solution because session level
information, such as temporary table, will be lost when you switch
master.

> MASTER_HOST='10.20.147.142',MASTER_PORT=3308,MASTER_USER='test',MASTER_PASS WORD='test',LOG_FILE='mysql-bin.000241',MASTER_LOG_POS=238108499;

>  5.1_mutil_master_repl.patch
> 27KViewDownload

[彭立勋]

can you give an example?

I start new thread for new replication, so each replication channel.

so different replication will not affect others.

2012/3/9 Jacky Shu <jack...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
To post to this group, send email to percona-d...@googlegroups.com.
To unsubscribe from this group, send email to percona-discuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/percona-discussion?hl=en.

[Jacky Shu]

Say you have two masters A and B, one slave C.

Try the following
1. on C: change master to A
2. on A: create temporary table tmp_tbl1
3. on C: change master to B
4. on C: change master to A
5. on A: insert into tmp_tbl1

slave C will complain after step 5 when replication catches up

On Mar 8, 8:35 pm, 彭立勋 <pengli...@gmail.com> wrote:
> can you give an example?
> I start new thread for new replication, so each replication channel.
> so different replication will not affect others.
>

> 2012/3/9 Jacky Shu <jackys...@gmail.com>

[Lixun Peng]

That's right, but if only one replication channel, this problem is still.

slave shutdown will destory temporary tables.

I think change master in one-master->Slave will be  destory temporary tables, too.

2012/3/9 Jacky Shu <jack...@gmail.com>