MySQL Replication, 主从和双主配置

MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。

配置主主同步的操作步骤：

MySQL-A     10.17.1.11

MySQL-B     10.17.1.12

1.     分别在两台机器授权账户：grant replication slave, file, select on *.* to 'repl'@'10.17.%' identified by ‘xxxx’ 

备注：如果想要在Slave上有权限执行 "LOAD TABLE FROM MASTER" 或 "LOAD DATA FROM MASTER" 语句的话，必须授予全局的 FILE 和 SELECT 权限。

2.     配置文件/etc/my.cnf，在使用主库配置文件的基础上，加入以下配置项

MySQL-A     MySQL-B

log-bin=mysql-bin	log-bin=mysql-bin
server-id=1	server-id=2
binlog-do-db=TestXXX	binlog-do-db=TestXXX
binlog-ignore-db=mysql	binlog-ignore-db=mysql
replicate-do-db=TestXXX	replicate-do-db=TestXXX
replicate-ignore-db=mysql	replicate-ignore-db=mysql
log-slave-updates	log-slave-updates
slave-skip-errors=all	slave-skip-errors=all
auto_increment_increment=2	auto_increment_increment=2
auto_increment_offset=1	auto_increment_offset=2

备注：

log-slave-updates是为从库的写操作记录binlog

多主互备和主从复制有一些区别，因为多主中的各个库，都可以对服务器有写权限，所以设计到自增长重复问题

模拟出现的问题（多主自增长ID重复）
假如我们在AB都建立一张test表，表中有一个auto increment的字段
停掉A的同步，在B上对数据表test(存在自增长ID)执行插入操作，返回插入ID为1
然后停掉B的同步，在A上对数据表test(存在自增长ID)执行插入操作，返回的插入ID也是1
然后同时启动A,B，就会出现主键ID重复

解决方法：

我们只要保证两台服务器上插入的自增长数据不同就可以了

如：A插入奇数ID，B插入偶数ID，当然如果服务器多的话，你可以定义算法，只要不同就可以了

在这里我们在A,B上加入参数，以实现奇偶插入

A：my.cnf上加入参数

[plain] view
plaincopy





auto_increment_increment=2  

auto_increment_offset=1  

这样A的auto_increment字段产生的数值是：1, 3, 5, 7, …等奇数ID了

B：my.cnf上加入参数

[plain] view
plaincopy





auto_increment_increment=2  

auto_increment_offset=2  

这样B的auto_increment字段产生的数值是：2, 4, 6, 8, …等偶数ID了

可以看出，你的auto_increment字段在不同的服务器之间绝对不会重复，所以Master-Master结构就没有任何问题了。当然，你还可以使用3台，4台，或者N台服务器，只要保证auto_increment_increment = N 再设置一下auto_increment_offset为适当的初始值就可以了，那样，我们的MySQL可以同时有几十台主服务器，而不会出现自增长ID重复。

         
3.     重启MySQL读取新的配置文件，进入MySQL后，用change master命令进行同步即可。

MySQL的Replication是一种多个MySQL的数据库做主从同步的方案，特点是异步，广泛用在各种对MySQL有更高性能，更高可靠性要求的场合。与之对应的另一个技术是同步的MySQL Cluster，但因为比较复杂，使用者较少。 

  

下图是MySQL官方给出了使用Replication的场景：



Replication原理 

  

Mysql 的 Replication 是一个异步的复制过程，从一个MySQL节点（称之为Master）复制到另一个MySQL节点（称之Slave）。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程（SQL 线程和 I/O 线程）在 Slave 端，另外一个线程（I/O 线程）在 Master 端。 

  

要实现 MySQL 的 Replication ，首先必须打开 Master 端的 Binary Log，因为整个复制过程实际上就是 Slave 从 Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 

  

看上去MySQL的Replication原理非常简单，总结一下： 

     * 每个从仅可以设置一个主。 

    * 主在执行sql之后，记录二进制log文件（bin-log）。 

    * 从连接主，并从主获取binlog，存于本地relay-log，并从上次记住的位置起执行sql，一旦遇到错误则停止同步。 

   

从这几条Replication原理来看，可以有这些推论： 

     * 主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间，主从数据不一致。 

    * 如果主从的网络断开，从会在网络正常后，批量同步。 

    * 如果对从进行修改数据，那么很可能从在执行主的bin-log时出现错误而停止同步，这个是很危险的操作。所以一般情况下，非常小心的修改从上的数据。 

    * 一个衍生的配置是双主，互为主从配置，只要双方的修改不冲突，可以工作良好。 

    * 如果需要多主的话，可以用环形配置，这样任意一个节点的修改都可以同步到所有节点。 

   
主从设置 

  

因为原理比较简单，所以Replication从MySQL 3就支持，并在所有平台下可以工作，多个MySQL节点甚至可以不同平台，不同版本，不同局域网。做Replication配置包括用户和my.ini（linux下为my.cnf）两处设置。 

  

首先在主MySQL节点上，为slave创建一个用户： 

  

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'192.168.1.10' IDENTIFIED BY 'slave'; 

  

实际上，为支持主从动态同步，或者手动切换，一般都是在所有主从节点上创建好这个用户。然后就是MySQL本身的配置了，这需要修改my.cnf或者my.ini文件。在mysqld这一节下面增加： 

  

server-id=1    

auto-increment-increment=2     

auto-increment-offset=1     

log-bin     

binlog-do-db=mstest     

binlog_format=mixed 

  

master-host=192.168.1.62    

master-user=slave     

master-password=slave     

replicate-do-db=mstest 

  

上面这两段设置，前一段是为主而设置，后一段是为从设置的。也就是说在两个MySQL节点上，各加一段就好。binlog-do-db和replicate-do-db就是设置相应的需要做同步的数据库了，auto-increment-increment和auto-increment-offset是为了支持双主而设置的（参考下一节），在只做主从的时候，也可以不设置。 

  
双主的设置 

  

从原理论来看MySQL也支持双主的设置，即两个MySQL节点互为主备，不过虽然理论上，双主只要数据不冲突就可以工作的很好，但实际情况中还是很容发生数据冲突的，比如在同步完成之前，双方都修改同一条记录。因此在实际中，最好不要让两边同时修改。即逻辑上仍按照主从的方式工作。但双主的设置仍然是有意义的，因为这样做之后，切换主备会变的很简单。因为在出现故障后，如果之前配置了双主，则直接切换主备会很容易。 

  双主在设置时，只需将上面的一段设置复制一份，分别写入两个MySQL节点的配置文件，但要修改相应的server-id，auto-increment-offset和master-host。auto-increment-offset就是为了让双主同时在一张表中进行添加操作时不会出现id冲突，所以在两个节点上auto-increment-offset设置为不同的值就好。  另：不要忘了，在两个节点上都为对方创建用户。  应用层的负载均衡  本文只介绍了MySQL自身的Repilication配置，在上面的图中也可以看出，有了Replication，还需要应用层（或者中间件）做一个负载均衡，这样才能最大程度发挥MySQL
Replication的优势，这些将在以后探讨。