环境：mac下的两台docker机
主库：172.17.0.2
从库：172.17.0.3
主从库分别设置 my.conf 里面的server_id 要不一样，一般跟ip最后一个值一样
主库查询：show master statusG;
从库执行：
change master to master_host = '192.168.1.100',master_user='repl',master_password='111111',master_log_file='mysqlmaster-bin.000004',master_log_pos=327;
log_file 和 log_pos 根据主库中查询的数字填写。重启。
show slave statusG;
Slave_IO_Running和Slave_SQL_Running两项都为yes，就表示主从复制配置成功了
问题：重启时报错 The server quit without updating PID file
解决：my.cnf配置错误。
问题：Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
解决：我是用docker镜像复制了两个一摸一样的环境，主从的server_id是后来设置的不一样，排除该问题。继续排查，找到原因在于，auto.cnf里面记录了数据库的uuid，每个库的uuid应该是不一样的。解决办法，原格式随意修改下，重启mysql即可。
测试通过!
记录：17-02-24
今天打开两台mysql，发现主从没有在同步。遂重新执行上句语句，发现Slave_IO_Running为connecting。排查后发现是由于连接主库的账号弄错了，所连账号没有权限导致。修改后正常。
测试当主从出错时的解决方案：
往主库的某个表写入一条数据，从库没有该表，从库出现错误。Slave_SQL_Running变成no。
解决办法：
mysql>set global sql_slave_skip_counter=1;
mysql>start slave;
跳过该句错误，重新开始同步。
1.修改用户密码：update user set password=PASSWORD('123') where user='xx';
资料记录:
1.这个参数主要作用是缓存innodb表的索引，数据，插入数据时的缓冲
默认值：128M
专用mysql服务器设置的大小： 操作系统内存的70%-80%最佳。
设置方法：
my.cnf文件
innodb_buffer_pool_size = 6G
此外，这个参数是非动态的，要修改这个值，需要重启mysqld服务。
2.sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。
从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
3.查找错误日志：
show variables like '%log_error%';