Summary
MySQL is the world's most popular open source database, open source software portfolio as an important part of LAMP (Linux + Apache + MySQL + Perl / PHP / Python), widely used in various applications. Web2.0 era, popular community forum software Discuz system and the whole network of Wordpress blog platform are to achieve the underlying architecture is based on MySQL. Web3.0 era, Ali Baba, Facebook, Google and other large Internet companies have adopted a more flexible build a mature large-scale MySQL database cluster. Ali cloud database MySQL version of MySQL source code branch-based Alibaba, after double 11 high concurrency, large amount of test data, has excellent performance and throughput. In addition, Ali cloud database MySQL version also has been optimized to read and write separation, data compression, intelligent tone excellent advanced features.
Separate read and write (Read / Write Splitting) so that the primary database transactional processing add, change, delete operation (INSERT, UPDATE, DELETE), the processing from the database SELECT query operations, high concurrency in large systems, separate read and write is to improve the performance very important tool. Separate read and write is the basis to achieve the MySQL master-slave synchronization, so for master-slave synchronization management it is very important.
RDS for MySQL data synchronization modes:
Data between the primary synchronization RDS for MySQL 5.1 asynchronous mode is used, the high performance asynchronous mode, but the drawback is a certain probability be inconsistencies between the primary backup data.
RDS for MySQL apparatus master data synchronization between 5.5 uses a semi-synchronous mode, this mode write performance will decline, but has the advantage that the probability of inconsistent data standby greatly reduced. If you have very high reliability requirements (such as the financial system) data, it is recommended that you purchase 5.5 above (including) version of RDS for MySQL.
RDS for MySQL 5.6 standby data synchronization between new features using MySQL 5.6 GTID, the characteristics that can ensure the performance, but also to ensure data consistency standby.
MYSQL master-slave synchronization effect:
1. Data Distribution
2. Load Balancing (Load Balancing)
3. backup (the Copy)
4. High Availability (high availability) and fault tolerance
Master synchronization from the detailed process is as follows:
1. The main server to verify the connection.
2. The primary server to open a thread from the server.
3. From the server, the main server log offset bit tells the master server.
4. Main server checks whether the value is less than the current bit offset binary log.
If less than 5, the notification from the server to fetch data.
6. taken from continuous data server from the primary server, take complete until this time, from the server thread to enter a sleep, the master server threads into sleep.
7. When the primary server is updated, the main server thread is active, and will be pushed to the binary log from a server, and notify into operation from the server thread.
8. Perform binary logs from the SQL thread, and then go to sleep.
MySQL to build a master-slave synchronization process:
(1) from the master synchronization environment Introduction
Operating system environments: Centos 64-bit
MYSQL version: MYSQL 5.1
IP master server: 192.168.106.1
from the server's IP: 192.168.106.2
(2) on the primary account number to establish synchronization server
Do not set permissions in time to set the password is too simple:
| 1 2 |
GRANT REPLICATION SLAVE,FILE ON *.* TO 'replication'@'192.168.106.%' IDENTIFIED BY 'mysqlpassword'; FLUSH PRIVILEGES; |
Change (3) from the server configuration file
server-id = 2
replicate-wild-ignore-table=mysql.%
log-slave-updates # that there is a need to open
(4) to get a snapshot from the master server version
If you are MYISAM or both MYISAM have INNODB, then use the following command on the primary server to export a snapshot of the server:
mysqldump -uroot -p --lock-tables --events --triggers --routines --flush-logs --master-data=2 --databases test > db.sql
Only INNODB then is to use the following command:
mysqldump -uroot -p --single-transaction --events --triggers --routines --flush-logs --master-data=2 --databases test > db.sql
It should be noted that the use of several parameters:
--single-transaction This parameter applies only to innodb.
behind --databases with other library name for all databases except mysql later, I am here only a test library.
--master-data parameters will be recorded export a snapshot when the mysql binary log position, one will be used.
(5) will be restored to the snapshot version from the server
mysqldump -uroot -p -h 192.168.106.2 test < db.sql
To restore the snapshot version from the server after, this time from the master server and the data on the server is the same.
(6) from the synchronization master server from the server using the change master
Use the grep command to find the name of the binary log and position
# grep -i "change master" db.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
CHANGE MASTER statement generation, and then executed from the
STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='192.168.106.1',MASTER_USER='replication',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
START SLAVE;
(7) This completes the synchronization from the master to build, use and finally
SHOW SLAVE STATUS;
View Slave_IO_Running and Slave_SQL_Running state, if all is Yes, then they succeeded.
Note: Do not sync information written into the configuration file so that management is not convenient, especially those changes need to restart.