First, copy the master-slave principle
1.1 Basic Introduction
MySQL built-in replication is the basis for building large, high-performance applications. The MySQL distributed to hundreds of millions of up to a plurality of systems, such a stepwise mechanism, is copied to other hosts (Slave) MySQL data by a certain host, and the instructions again achieved. During replication server acts as a primary server, while one or more other servers act as from the server. The master server updates written to the local binary log files and maintains an index file to track log cycle. These log records can be sent from the server to update. When a connection from the master server, it informs the primary server, any updates since then received from the server from the occurrence of the last successful location update server reads in the log, the master server and wait for a new update notification.
Note: All data must be updated on the master server from the copy when you configure the master. Otherwise, you have to be careful to avoid conflicts between updates for the user list on the main server and updates from the table on the server.
1.2 Mysql support copy type
Copy statements based. What sql statement executed in the main server, the server will automatically re-executed from it again. No Otherwise, you have to be careful to avoid conflicts between updates for the user list on the main server and updates from the table on the server. Configured: binlog_format = 'STATEMENT'
Row-based replication. Copy the contents of the change of the past, rather than executing commands from the server again, beginning from MySQL 5.0 support, configuration: binlog_format = 'ROW'
Mixed types of replication. The default statement-based replication, if it is found based on statements can not be precisely replicated, will use row-based replication, configuration: binlog_format = 'MIXED'
1.3 Master-slave replication can solve the problem
Primary database problem, can be switched to the slave database (high availability and fault tolerance)
Separate database level can be read (load balancing to reduce the pressure master node)
From the library can be used as a backup database
1.4 Realization master copy from the common
A master multi-slave replication architecture
Scenario:
The pressure in the master library read request very large scene can be more achieved by arranging a separate read and write from the master copy architecture, a large amount of real-time requirements are not particularly high load balancing by scheduling a read request to the plurality from the library, reducing the pressure of the main reading library. In the case of abnormal downtime of the main library, the library can be a switch from the main library continue to provide services
Precautions:
-
When Slave to a certain amount, Slave to Master load and network bandwidth will become a serious problem.
Slave different play different roles (e.g., using different indexes, or different storage engines)
As a backup Master, replicate only by a Slave
With a remote Slave, for disaster recovery.
Multi-level replication architecture
Scenario:
A master multi-slave architecture can solve most read requests scenes pressure particularly large demand, but the main library I / O network pressure and the pressure will increase as the library grows, the use of multi-level replication architecture can solve a more from the main scenario, the primary database additional I / O and network pressure. But note that the multi-level data replication scenario at the main library is experiencing twice before reaching the read from the delay library, during a multi-scene experience than just copy from a master copy of a larger
Precautions:
-
There may be a longer delay risk
This scheme can be combined with the use of third-party software, e.g. Slave + LVS + Keepalived high availability.
Dual master replication architecture
Scenario:
Dual master / Dual Master framework applicable to the scenario writing pressure is relatively large, or DBA needs to do to maintain the master switch from the scene by double master / Dual master architecture to avoid duplication of structures from a library of trouble
Precautions:
-
The biggest problem is to update conflict.
It can be used MySQL Cluster, and the Replication and Cluster together, can create a powerful, high-performance database platform
1.5 Master-Slave Replication Works
The basic data replication between MySQL binary log file (binary log file). Once a MySQL database binary logging is enabled, as master, all operations will be its database to "events" recorded in the binary log (bin log) files, other databases as slave via an I / O thread changes in the master binary log file bin log dump maintain communications, and monitor master, and if found master binary log file is changed, it will copy the data to change their relay log, then slave SQL thread reads relay logs, and sequentially the event log sql instructions again, in order to ensure data consistency with the primary server
Simple roughly divided into the following three steps:
Step: master data is updated before each transaction is completed, the recording operation binlog serially written to a file.
Step Two: salve opening a I / O Thread, the thread opens a connection in common master, it is the main work binlog dump process. If progress has been read to keep up with the master, they go to sleep and wait for the master to generate a new event. The final purpose I / O thread that writes these events to the relay log.
The third step: SQL Thread reads the relay log, and sequentially executing the SQL event log, so the data is consistent with the primary database.
Details Description:
Master Record binary logs. Before each transaction update data, Master record these changes in the binary log. The MySQL binary logs written statement metropolis transaction log and timely execution of cross affairs. After the completion of the event written to the binary log, Master notify the storage engine to commit the transaction.
Slave to the Master Binary log copies to its own relay logs. First Slave to start a worker thread -I / O thread. I / O thread opens a connection on the Master, then start reading the binary log event, even if you have a Master, master it and wait for a new event. I / O thread of these events are written to the relay log.
SQL Slave Thread (SQL slave thread) processing the final step of the process. SQL purebred read events from the relay log and replay of events in which data is updated Slave. Other data that the Master is consistent. As long as the thread and I / O threads consistent relay log usually located in the OS cache, so the overhead is small relay logs.
Here, the Master also has a worker thread, and other connections, like MySQL, Slave Master opens a connection will make the Master start a thread. Replication process has a very important limitation - on the Slave replication is serialized, that is parallel update on the Master can not operate in parallel on the Slave.
Two, mysql actual master-slave configuration
2.1 Configuration Simple implementation steps
Master:
- Enable binary logging
- configure a unique server-id
- obtain master binary log file name and location
- Create a user account for the slave and master communication
From the server:
- configure a unique server-id
- Use the master assigned user account read master binary log
- Enable slave Services
2.2 Configuration Considerations
-
Each Slave can have only one Master;
Each Slave can only have a unique server ID;
Each Master can have many Slave;
If you set the log_slave_updates, Slave may be other Slave's Master, Master of updates to diffuse
MySQL does not support multi-master replication - that can have more than a Slave Master, however, some simple combinations, but we can build a flexible and powerful replication architecture.