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

有关--master-data参数说明

导出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，说明很可能是从库与主库的数据不一致。