Principle and implementation of MySQL master-slave database
MySQL's master-slave synchronization architecture is a popular database architecture at present. Using MySQL's master-slave configuration, it can realize read-write separation, reduce the access pressure of the master database, and improve website performance.
Master-slave principle:
1. The master records the binary log. Before each transaction updates the data, the master records these changes in the second log. MySQL writes transactions serially to the binary log, even if the statements in the transaction are executed interleaved. After events are written to the binary log, the master notifies the storage engine to commit the transaction.
2. The slave starts an I/O thread that establishes a normal link on the Master, and then starts the binlog dump process. The Binlog dump process reads events from the master's binary log, and if it has caught up with the master, it sleeps and waits for the master to generate new events. The I/O thread writes these events to the relay log.
3. The SQL thread reads events from the relay log, and replays the events to update the slave data to be consistent with the data in the master. As long as the thread is consistent with the I/O thread, the relay log will usually be in the OS's cache, so the overhead of the relay log is small.
Notice:
There is also a worker thread in the master: like other MySQL connections, a slave opening a connection in the master causes the master to start a thread. The replication process has an important limitation - replication is serialized on the slave, which means that parallel update operations on the master cannot be performed in parallel on the slave.
master-slave configuration
Host A: 192.168.1.100
Slave B: 192.168.1.101
1. Log in to host A first
mysql>GRANT REPLICATION SLAVE ON *.* TO ‘backup’@’192.168.1.101‘ IDENTIFIED BY ‘123456’;
Grant slave permissions, if there are multiple cluster machines, execute multiple times
backup is the authorized account, 123456 is the password
2. Open my.cnf of host A and enter
server-id = 1 #host identifier, integer
log_bin = /var/log/mysql/mysql-bin.log #确保此文件可写
read-only =0 #主机，读写都可以
binlog-do-db =test #需要备份数据，多个写多行
binlog-ignore-db =mysql #不需要备份的数据库，多个写多行
3、打开从机B的my.cnf，输入
server-id = 2
log_bin = /var/log/mysql/mysql-bin.log
master-host =192.168.1.100
master-user =backup
master-pass =123456
master-port =3306
master-connect-retry=60 #如果从服务器发现主服务器断掉，重新连接的时间差(秒)
replicate-do-db =test #只复制某个库
replicate-ignore-db=mysql #不复制某个库
4、同步数据库
不用太费事，只把主从库都启动即可自动同步，如果不嫌麻烦的话可以把主库的内容导出成SQL，然后在从库中运行一遍
5、先重启主机A的mysql，再重启从机B的mysql
6、验证
在主机A中，mysql>show master status\G;
在从机B中，mysql>show slave status\G;
Slave_IO_Running 和 Slave_SQL_Running, 必须都为 Yes
添加新slave服务器
假如master已经运行很久了，想对新安装的slave进行数据同步，甚至它没有master的数据。
此时，有几种方法可以使slave从另一个服务开始，例如，从master拷贝数据，从另一个slave克隆，从最近的备份开始一个slave。Slave与master同步时，需要三样东西：
1. master的某个时刻的数据快照；
2. master当前的日志文件、以及生成快照时的字节偏移。这两个值可以叫做日志文件坐标(log file coordinate)，因为它们确定了一个二进制日志的位置，你可以用SHOW MASTER STATUS命令找到日志文件的坐标；
3. master的二进制日志文件。
主从运维
1. 确保从库的两个线程都是正常运行的
Slave_IO_Running: Yes Slave_SQL_Running: Yes
如可监控和报警：
编写一shell脚本，用nagios监控slave的两个yes（Slave_IO及Slave_SQL进程），如发现只有一个或零个yes，就表明主从有问题了，发短信警报吧。
2. 出现“log event entry exceeded max_allowed_pack”错误
如果在应用中使用大的BLOB列或CLOB列或者长字符串，那么在从服务器上回复时，可能会出现“log event entry exceeded max_allowed_pack”的错误，这是因为含有大文本的记录无法通过网络进行传输而导致的。
show variables LIKE '%max_all%' Variable_name Value ------------------ ------- max_allowed_packet 1048576 (1 row(s) affected)
解决方法：
同时在my.ini或my.cnf文件里设置max_allowed_packet=16M，数据库重启之后该参数将有效
set @@global.max_allowed_packet=16777216;
3. 多主复制时自增长冲突
大多数情况下使用一台主服务器对一台或者多台从服务器，但是在某些情况下可能会存在多个服务器配置为复制主服务器，使用auto_increment时应采取特殊步骤以防止键值冲突，否则插入时多个主服务器会试图使用相同的auto_increment值
解决方法：
在这里我们在A,B上加入参数，以实现奇偶插入
A：my.cnf上加入参数
auto_increment_offset = 1
auto_increment_increment = 2
这样A的auto_increment字段产生的数值是：1, 3, 5, 7, …等奇数ID了
B：my.cnf上加入参数
auto_increment_offset = 2
auto_increment_increment = 2
这样B的auto_increment字段产生的数值是：2, 4, 6, 8, …等偶数ID了
提示：
一般不建议使用双主或多主，因为这样会带来意想不到的冲突状况，就像SQLSERVER的对等复制，虽然有很多冲突检测措施。但是有时候冲突是不可预料的，出现冲突DBA要排查，维护成本较高，我们生产环境里是没有使用双主和多主，主要使用的是一主多从或一主一从
参考：
http://blog.csdn.net/hguisu/article/details/7325124/
http://369369.blog.51cto.com/319630/790921/
https://my.oschina.net/u/730579/blog/632790
http://www.cnblogs.com/xiao-yu/archive/2011/06/14/2080842.html