Mysql master-slave replication Principles and Practice
from the main frame mysql
MySQL Cluster MySQL master-slave architecture is the most basic and most commonly used as a framework to deploy to meet the needs of many businesses, there is a common master-slave or a master multi-slave. Single host can prevent data loss, to improve data security, service may be implemented on separate read and write, a read operation can be performed from a number of servers, to reduce the burden on the host server.
### master-slave principle replication
mysql replication from the master means data can be copied from a server node to a mysql or a plurality mysql servers, a plurality of asynchronous manner from a server to update the primary database. MySQL is a subscription-based master-slave synchronization from the library to achieve incremental main library binlog file, write the type of event to update the main library binlog file, the log records all update the data or have the potential of all updated data statement, in the form of "events" to save, which describes the data changes, it is stored in binary form on disk. Ending .000001 way, binlog file size and the number will continue to increase, when mysql restart, the number will continue to increase.
Schematics from the primary copy:
For each connection from a master to complete, require three processes, master (binlog dump thread), slave (I / O thread, SQL thread).
- The master node is a binary log dump process from each node to build a current connection
- After executing a command from the start slave node, the node is created from an I / O thread is used to connect the master node, the request to update the master library bin-log. After the update I / O thread receives binlog dump process to the master node, stored in a local relay-log.
- SQL thread is responsible for reading the content relay log in, resolve into concrete action and execution, and ultimately ensure the consistency of data from the master. Entire synchronous operation is executed asynchronously.
The following stresses in the linux achieved from an associated master system synchronization steps:
Main Library Configuration
- Open binglog log master's,
- Create a unique server_id,
- And no need to specify database and synchronization of database to be synchronized
1, edit my.cnf file
vi /etc/my.cnf
2, add the configuration:
log-bin=master-bin
server-id=1
#需要同步的数据库
binlog-do-db=shoes
#不需要同步的mysql系统数据库
binlog-ignore-db=mysql
3, grant permissions from the database replication
grant replication slave on *.* to 'root'@'192.168.48.133' identified by '123456';
Here's ip address and user passwords are from the library, if prompted: Your password does not satisfy the current policy requirements explain your password is unsafe, need to set the parity level passwords, self-Baidu.
After setting, restart the master of mysql service.
Use the command: mysql -uroot -pAfter logging in mysql service, executeshow master status；
Information will appear similar to that shown in FIG:
File and record the value of Position, back when required configuration from the library.
Well, here the main library configuration is completed, the next is from the library configuration.
Also modify the my.cnf file, add the following information:
server-id=2
log-bin=mysql-bin
replicate-do-db=shoes
replicate-ignore-db=mysql
The configuration information is connected to the master server:
mysql> CHANGE MASTER TO
-> MASTER_HOST='192.168.48.128',
-> MASTER_USER='root',
-> MASTER_PASSWORD='123456',
-> MASTER_LOG_FILE='mysql-bin.000002',
-> MASTER_LOG_POS=7641;
mysql> start slave;
MASTER_LOG_POS here is to tell the slave library where to start copying from the master binary log, which is the earlier view of the main library status value of Position.
And then view the slave status:
mysql>show slave status\G
Message shown appears:
When there Slave_IO_Running and Slave_SQL_Running is yes, and Slave_IO_State is: Waiting for master to send event of the time, the configuration is successful. Connecting to ... if it is not explained on the company, this time to check the next ip address, account number or firewall problem.
In the replication process, due to some other improper operation, you may encounter similar problems as shown,
这种情况比如说我在从库上把数据删掉了，然后主库又进行删除，此时找不到从库上对应的记录就会报错，当发生这样的错误之后，从库就无法更新主库的数据了。如果主库都已经删除了，那么从库也就没有必要保留了，这种情况的话可以设置从库复制的时候跳过当前这个事件，需要暂停slave操作:
stop slave;
set global sql_slave_skip_counter=1;
start slave;
类似的问题还有比如说重复插入，更新丢失，relay log 损坏等，都可以采取相应的策略来恢复，如重新选择到同步的binlog和POS点，然后重新做同步等。
binlog日志文示例
使用命令
mysql> show binlog events in 'mysql-bin.000002;
查看binlog日志。
binlog的日志格式
mysql的binlog格式分为三种：
Statement
每一条会修改数据的 SQL 都会记录到 master 的 bin-log 中。slave 在复制的时候 SQL 进程会解析成和原来 master 端执行过的相同的 SQL 再次执行。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题
row
日志中会记录成每一行数据被修改的形式，然后在 slave 端再对相同的数据进行修改。
优点：Binnary Log可以不记录执行的Query语句的上下文相关信息，不会出现某些特定情况下存储过程或function，以及trigger的调用和触发器无法被正确复制的问题。
缺点：如果批量修改数据，记录的不是批量修改的SQL语句事件，而是每条记录被更改的SQL语句，比如说update语句，会记录每一行被修改的sql语句，当alter表的时候，更是会产生大量的日志。
Mixedlevel
以上两种的结合体，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。
因此，企业生产上使用哪种弄场景可以根据具体的场景来选择合适的格式。
查看binlog格式使用命令：
mysql> show global variables like "%binlog_format%";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
格式可以在my.cnf文件中进行配置：
binlog_format="ROW"
或者在运行时动态的修改格式：
mysql> SET SESSION binlog_format = 'STATEMENT';
通过mysql复制可以将读操作分布在多个服务器上，实现对密集型应用的优化，通过简单的代码修改就可以实现基本的负载均衡，并且能够帮助应用程序避免mysql的单点故障，实现mysql的高可用性。
