Multi-source copy of MySQL 5.7

Why 80% of the code can not do farming architect? >>>  

ORACLE has recently released several new features in the latest version of Mysql5.7.2, which has this article. Most of the improvement is on database performance and replication-related functions, this new version will bring us magical. In this article, I will use some simple step-outs to try to understand this new multi-source replication works and how we conduct their own tests. It should be noted that this is a development version, not to the production environment to prepare. Therefore, this article is intended for those who want to understand this new feature and see how it works in the application, is related operations in the temporary environment. What is multi-source copy? First, we need a clear multi-master and multi-source copy is not the same. Multi-Master replication generally annular copy, you can copy to other hosts on any host on the data. Multi-source is different. MySQL fixes a copy restrictions in this new version, this limitation is a slave can only have one master. This is a limiting factor in our design replication environment, there are some geeks make it is working well. But now there is a solution to the official. and so. Simply put, Multi-Source means that a slave can have more than one master now, as shown in the image replication environment is possible: This will help us create some hierarchy replication, which is not possible in the past . For example, you can put one on your office from the station. Copy the data from all the main stations in the office spread around the world. It is how does it work? Now that we have the concept of communication channels, each communication channel is a link to obtain binary logs from the master server from the server. This means that each communication channel had to have a IO_THREAD. We need to run different "CHANGE MASTER" command for each primary server. We need to use the "FOR CHANNEL" this parameter to provide the name of the communication link.

CHANGE MASTER MASTER_HOST='something', MASTER_USER=... FOR CHANNEL="name_of_channel";

It is easy to have a single prerequisite. We need to configure security features on mysql5.6 from the server, which means that information is usually included on the primary server. Or log information should be in a table, let's start to configure it. Examples First you need to download the beta version of mysql.

# wget http://downloads.mysql.com/snapshots/pb/mysql-multi-src-repl/mysql-5.7.2-labs-multi-src-rep-linux-glibc2.5-x86_64.tar.gz

We need to have a sandbox environment from the server and two master servers. I will not explain the details of how to configure server_id, binary logs and replication users. I assume that is already configured. First of all, we realize accident safety functions from the server.

master_info_repository=TABLE;
relay_log_info_repository=TABLE;

Then restart the server. We can begin to create channels of communication with "master1" and "master2" two names:

slave > change master to master_host="127.0.0.1", master_port=12047, master_user="msandbox",master_password="msandbox" for channel="master1";
slave > change master to master_host="127.0.0.1", master_port=12048, master_user="msandbox",master_password="msandbox" for channel="master2";

The communication name set to boot from the server.

slave > start slave for channel="master1";
slave > start slave for channel="master2";

We now check the status from the server:

slave > show slave status\G
Empty set (0.00 sec)

what. It is empty. We need to write the name of the communication. Under re-examination from the server status:

slave > SHOW SLAVE STATUS FOR CHANNEL="master1"\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 127.0.0.1
                  Master_User: msandbox
                  Master_Port: 12047
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 232
               Relay_Log_File: squeeze-relay-bin-master1.000003
                Relay_Log_Pos: 395
        Relay_Master_Log_File: mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
[...]

We can also check IO_THREAD and SQL_THREADS running:

slave > SHOW PROCESSLIST;
+----+-------------+-----------------------------------------------------------------------------+
| Id | User        | State                                                                       |
+----+-------------+-----------------------------------------------------------------------------+
|  2 | system user | Waiting for master to send event                                            |
|  3 | system user | Slave has read all relay log; waiting for the slave I/O thread to update it |
|  4 | system user | Waiting for master to send event                                            |
|  5 | system user | Slave has read all relay log; waiting for the slave I/O thread to update it |
+----+-------------+-----------------------------------------------------------------------------+

Testing a look:

master1 > create database master1;
master2 > create database master2;
slave > show databases like 'master%';
+--------------------+
| Database (master%) |
+--------------------+
| master1            |
| master2            |
+--------------------+

Conclusion This new feature allows multi-source some complex operations in the past need to create a replication environment becomes simple. Of course, you can consider this application design and development of new properties, the use of multi-master, multi-source need special attention, do not put your data messed up. In each new version, mysql replication features give us more of configuration, performance and design possibilities. All of these new features can be combined. Increase replication in your new (old) function in your replication environment will be better. For example: You can configure GTID can use multi-threaded slave per schema or intra-database article reproduced from osc..

Reproduced in: https: //my.oschina.net/766/blog/211370