Mysql5.6主从复制-基于binlog
MySQL5.6开始主从复制有两种方式：基于日志（binlog）；基于GTID（全局事务标示符）。
看MySQL的My.ini,看服务的启动配置到那个配置文件。
根据《烂泥：学习mysql数据库主从同步复制原理》文章可知，mysql的主从同步复制过程如下：
1、主库master在执行SQL语句之后，会把相关的SQL语句记录到binlog文件中。
2、从库slave连接主库master，并从主库master获取该binlog文件，存于本地relay-log文件中，然后从master.info文件读取上次同步时的pos位置节点起执行SQL语句。
由以上信息可知，我们的mysql主从同步复制实验，需要以下几个步骤：
1、 配置主库master同步复制时的选项
2、 在主库master上创建同步复制时的用户并授权
3、 主库master锁表
4、 记录主库master的binlog以及pos位置节点
5、 导出ilanni数据库
6、 配置slave端同步复制时所需要的选项
7、 在从库slave上创建数据库ilanni并导入备份
8、 解锁主库表
9、 设置从库slave与主库master同步
10、 在从库slave上开启同步
11、 查看从库slave的relay-log以及master.info
12、 测试主从同步
此文章是基于日志方式的配置步骤
环境：
master数据库IP：192.168.247.128
slave数据库IP：192.168.247.130
mysql版本：5.6.14
1.修改master配置文件并重启服务：
[mysqld]
server_id=1
binlog-ignore-db=test #不记录binlog
replicate-ignore-db=test #不复制test库的binlog
log-bin=mysql-bin
binlog_cache_size = 1M
binlog_format=mixed
expire_logs_days=3
其中log-bin=mysql-bin表示启用mysql二进制日志，该项必须要启用，否则mysql主从不会生效。
max_binlog_size=500M表示每个binlog文件最大大小，当此文件大小等于500M时，会自动生成一个新的日志文件。注意：一条记录不会写在2个日志文件中，所以有时日志文件会超过此大小。
server-id=1表示mysql服务器ID，该ID必须在该主从中是唯一的，默认是1，该ID可以自行自定义，但必须为数字。
binlog-do-db=ilanni表示需要同步的数据库名字，如果是多个数据库，就以此格式再写一行即可。
binlog-ignore-db=mysql表示不需要同步的数据库名字，如果是多个数据库，就以此格式再写一行即可。
注意：如果binlog-do-db和binlog-ignore-db不加的话，那么默认是同步复制整个mysql数据库。
二、在主库master上创建同步复制时的用户并授权
登录master端，创建数据库用户ilanni，并授权为replication slave权限。如下：
grant replication slave on *.* to 'ilanni'@'%' identified by '123456';
select user,repl_slave_priv from user where user='ilanni';
2.修改slave配置文件并重启服务：
[mysqld]
server_id=2
binlog-do-db = mydb
binlog-ignore-db=test #不记录binlog
replicate-ignore-db=test #不复制test库的binlog
log-bin=mysql-bin
binlog_cache_size = 1M
binlog_format=mixed
expire_logs_days=3
3.在master上建立用于复制的用户
mysql>grant replication slave, replication client on *.* to 'repl'@'192.168.247.130' identified by 'pwd';
登录master端，创建数据库用户ilanni，并授权为replication slave权限。如下：
我们可以看到目前数据库用户ilanni被授予replication slave权限，在user表中的表现为repl_slave_priv字段为Y。
注意：replication slave权限：只有拥有此权限的用户才可以查看从服务器slave以及从主服务器master读取二进制日志的权限。
4.备份master的数据
方法1：数据前先锁表，保证数据一致性
先锁住主库master的表，防止数据再写入，导致主从数据库不一致。使用如下命令锁表：
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
+—————–+————+—————-+——————–+
|File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+—————–+————+—————-+——————–+
|mysql-bin.000015 | 1273 | | |
+—————–+————+—————-+——————–+
记录文件名和pos号
开始备份数据库
# mysqldump -uroot -p mydb > /tmp/mydb.sql
备份完毕，现在可以解锁数据库表
mysql> UNLOCK TABLES;
方法2：使用--lock-all-tables和--master-data参数结合，导出数据
# mysqldump -uroot -p --hex-blob --lock-all-tables -R --triggers --databases mydb --master-data=2 --default-character-set='utf8' --quick> /tmp/mydb.sql
导出ilanni数据库
在从库slave与主库master第一次同步数据时，有三种方法。
第一种方法就是在主库锁表后，使用tar把master库直接打包，然后使用scp或者rsync把该打包文件弄到从库slave上。这种情况一般适用于网站或者业务在初始化，抑或在数据库大于100G时建议使用。
第二种方法就是在主库锁表后，我们直接使用mysqldump命令导出数据库，然后在从库上进行恢复。这个方法比较常见，所以我们一般是使用这个方法。
注意以上两种方法，我们都需要进行在主库master锁表后进行操作。
第三种方法，其实我们不需要做其他工作。只需开启同步复制即可。但是这个有一个前提就是，mysql的binlog必须齐全，这个齐全就是要包括该数据创建时的binlog也要存在。并且同步时，还必须要从最初始的binlog开始。所以，这种方法，我们一般不使用。
5.拷贝备份文件到slave，并导入
#scp /tmp/mydb.sql
#mysql -uroot -p -B mydb </tmp/mydb.sql
6.在slave上同步binlog
mysql>CHANGE MASTER TO MASTER_HOST='192.168.247.128',MASTER_USER='repl',MASTER_PASSWORD='pwd',MASTER_LOG_FILE='mysql-bin.000015',MASTER_LOG_POS=1273;
如果是方法2导出的数据，则通过以下语句查询binlog文件名和pos位置：
# grep -i "CHANGE MASTER TO" /tmp/mydb.sql
--CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=1273;
7.开启复制
mysql> START slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)
8.查看slave状态
mysql> show slave status\G
Slave_IO_Running: YES
Slave_SQL_Running: Yes
2个YES说明配置成功
Slave_IO_Running：连接到主库，并读取主库的日志到本地，生成本地日志文件
Slave_SQL_Running:读取本地日志文件，并执行日志里的SQL命令。
如果Slave_IO_Running为NO，说明可能是从库与主库的网络不通。
如果Slave_SQL_Running为NO，说明很可能是从库与主库的数据不一致。
