环境配置
调试信息如下，linux6.8， mysql5.6.42版本，两台虚拟机，分别为192.168..100 和192.168..101, 以下简称100和101， 101为主节点，100为从节点，采用一主一从的配置方式。 my.cnf的文件位置在/etc/my.cnf中。具体的my.cnf的加载顺序：
不同的操作系统加载顺序可能不同，具体查看自己的机器加载顺序可以使用如下命令：
./bin/mysql --help|grep my.cnf
eg:
OS：CentOS 7
MySQL：MySQL 5.7
MySQL安装目录：/usr/local/mysql
加载顺序为：
- /etc/mysql/my.cnf->
- /etc/my.cnf->
- ~/.my.cnf
eg：
OS：CentOS 6
MySQL：MySQL 5.6
MySQL安装目录：/application/mysql-5.6.44
加载顺序为：
- /etc/my.cnf->
- /etc/mysql/my.cnf->
- /application/mysql-5.6.44/etc/my.cnf->
- ~/.my.cnf
总结
“如果几个配置文件中都有同一个参数，MySQL数据库以哪个配置文件为准？”
答案很简单，MySQL数据库会以读取到的最后一个配置文件中的参数为准。
数据文件目录为/usr/local/mysql/data目录下。
mysql基本安装步骤略去，后面有时间会补充基本安装步骤。
配置主节点
- 在[mysqld]配置项中 配置server-id=1， 注意是server ，不是service，手误，踩过坑
- 启用binlog日志，在[mysqld] 配置项中设置 log-bin = mysql-bin， 也可以指定具体文件路径
如：log-bin=/usr/local/mysql/data/mysqlbinlog/mysql-bin
log-bin配置项表示binlog的base name，产生的日志文件名称类似，mysql-bin.00001，mysql-bin.00002，mysql-bin.00003。
以上两步为必选项，下面为可选项
- log-bin=/usr/local/mysql/data/mysqlbinlog/mysql-bin 设置错误日志文件目录
- binlog-do-db = db 要复制的数据库名，如果复制多个数据库，重复设置这个选项即可
完成以上配置项后，其中1.2必选，3,4可选，重启mysql服务
在mysql命令行中执行如下命令：
grant replication slave on *.* to 'root'@192.168.92.100 identified by '123456'
具体含义如图：
2.执行该命令： flush privileges;
-
执行show master status命令
图片.png
简单说： 从mysqlbin.000035这个文件的341行开始复制，binlog_do_db 是哪些数据库需要同步，Binlog_Ingore_db表示忽略哪些数据库
以下是几个比较常用的命令：
- 查看日志开启状态 show variables like 'log_%';
- 查看所有binlog日志列表 show master logs;
- 查看最新一个binlog日志的编号名称，及其最后一个操作事件结束点 show master status;
至此 master基本配置完成。 - 刷新log日志，立刻产生一个新编号的binlog日志文件，跟重启一个效果 flush logs;
- 清空所有binlog日志 reset master;
-
日志查看，因为是二进制文件没法用vi等打开，可以用mysql的mysqlbinlog打开，/usr/bin/mysqlbinlog /home/logs/mysql-bin.000001，当然每个人路径可能不一样，这个只能自己去找了
图片.png
从节点配置
- 修改my.cnf的【mysqld】配置项，增加server-id=2 属性
- 也可以开启binlog日志 日志选项
- 本地测试，避免出现连接问题，关闭防火墙测试
在100机器mysql命令行执行：
CHANGE MASTER TO MASTER_HOST='192.168.92.101', MASTER_USER='root', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=120;
-
执行 start slave ，报错了
图片.png
查了点资料，解决方法：
找到原因所在了，由于我使用的是冷备份文件恢复的实例，在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息，所以导致启动slave报错。
mysql提供了工具用来删除记录：reset slave ；
slave reset执行候做了这样几件事：
1、删除slave_master_info ，slave_relay_log_info两个表中数据；
2、删除所有relay log文件，并重新创建新的relay log文件；
-
重新执行start slave 成功
图片.png -
查看状态：show slave status \G;
图片.png
其中首先关注的是两个线程的状态
Slave_IO_Running: Yes
Slave_SQL_Running: No
Yes表示正常，No表示异常
Slave_IO线程负责把主库的bin日志(Master_Log)内容，抄写到从库的中继日志上(Relay_Log)。
Slave_SQL线程负责把中继日志上的语句在从库上执行一遍。
以上各个属性的解释：
Slave_IO_State
SHOW PROCESSLIST输出的State字段的拷贝。SHOW PROCESSLIST用于从属I/O线程。如果线程正在试图连接到主服务器，正在等待来自主服务器的时间或正在连接到主服务器等，本语句会通知您
Master_User
被用于连接主服务器的当前用户。
Master_Port
当前的主服务器接口。
Connect_Retry
--master-connect-retry选项的当前值
Master_Log_File
I/O线程当前正在读取的主服务器二进制日志文件的名称。
Read_Master_Log_Pos
在当前的主服务器二进制日志中，I/O线程已经读取的位置。
Relay_Log_File
SQL线程当前正在读取和执行的中继日志文件的名称。
Relay_Log_Pos
在当前的中继日志中，SQL线程已读取和执行的位置。
Relay_Master_Log_File
由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称。
Slave_IO_Running
I/O线程是否被启动并成功地连接到主服务器上。
Slave_SQL_Running
SQL线程是否被启动。
Replicate_Do_DB,Replicate_Ignore_DB
使用--replicate-do-db和--replicate-ignore-db选项指定的数据库清单。
Replicate_Do_Table,Replicate_Ignore_Table,Replicate_Wild_Do_Table,Replicate_Wild_Ignore_Table
使用--replicate-do-table,--replicate-ignore-table,--replicate-wild-do-table和--replicate-wild-ignore_table选项指定的表清单。
Last_Errno,Last_Error
被多数最近被执行的查询返回的错误数量和错误消息。错误数量为0并且消息为空字符串意味着“没有错误”。如果Last_Error值不是空值，它也会在从属服务器的错误日志中作为消息显示。
举例说明：
Last_Errno: 1051
Last_Error: error 'Unknown table 'z'' on query 'drop table z'
该消息指示，表z曾经存在于在主服务器中并已被取消了，但是它没有在从属服务器中存在过，因此对于从属服务器，DROP TABLE失败。（举例说明，在设置复制时，如果您忘记了把此表拷贝到从属服务器中，则这有可能发生。）
Skip_Counter
最近被使用的用于SQL_SLAVE_SKIP_COUNTER的值。
Exec_Master_Log_Pos
来自主服务器的二进制日志的由SQL线程执行的上一个时间的位置（Relay_Master_Log_File）。在主服务器的二进制日志中的(Relay_Master_Log_File,Exec_Master_Log_Pos)对应于在中继日志中的(Relay_Log_File,Relay_Log_Pos)。
Relay_Log_Space
所有原有的中继日志结合起来的总大小。
Until_Condition,Until_Log_File,Until_Log_Pos
在START SLAVE语句的UNTIL子句中指定的值。
Until_Condition具有以下值：
如果没有指定UNTIL子句，则没有值
如果从属服务器正在读取，直到达到主服务器的二进制日志的给定位置为止，则值为Master
如果从属服务器正在读取，直到达到其中继日志的给定位置为止，则值为Relay
Until_Log_File和Until_Log_Pos用于指示日志文件名和位置值。日志文件名和位置值定义了SQL线程在哪个点中止执行。
Master_SSL_Allowed,Master_SSL_CA_File,Master_SSL_CA_Path,Master_SSL_Cert,Master_SSL_Cipher,Master_SSL_Key
这些字段显示了被从属服务器使用的参数。这些参数用于连接主服务器。
Master_SSL_Allowed具有以下值：
如果允许对主服务器进行SSL连接，则值为Yes
如果不允许对主服务器进行SSL连接，则值为No
如果允许SSL连接，但是从属服务器没有让SSL支持被启用，则值为Ignored。
与SSL有关的字段的值对应于--master-ca,--master-capath,--master-cert,--master-cipher和--master-key选项的值。
Seconds_Behind_Master
本字段是从属服务器“落后”多少的一个指示。当从属SQL线程正在运行时（处理更新），本字段为在主服务器上由此线程执行的最近的一个事件的时间标记开始，已经过的秒数。当此线程被从属服务器I/O线程赶上，并进入闲置状态，等待来自I/O线程的更多的事件时，本字段为零。总之，本字段测量从属服务器SQL线程和从属服务器I/O线程之间的时间差距，单位以秒计。
如果主服务器和从属服务器之间的网络连接较快，则从属服务器I/O线程会非常接近主服务器，所以本字段能够十分近似地指示，从属服务器SQL线程比主服务器落后多少。如果网络较慢，则这种指示不准确；从属SQL线程经常会赶上读取速度较慢地从属服务器I/O线程，因此，Seconds_Behind_Master经常显示值为0。即使I/O线程落后于主服务器时，也是如此。换句话说，本列只对速度快的网络有用。
即使主服务器和从属服务器不具有相同的时钟，时间差计算也会起作用（当从属服务器I/O线程启动时，计算时间差。并假定从此时以后，时间差保持不变）。如果从属SQL线程不运行，或者如果从属服务器I/O线程不运行或未与主服务器连接，则Seconds_Behind_Master为NULL（意义为“未知”）。举例说明，如果在重新连接之前，从属服务器I/O线程休眠了master-connect-retry秒，则显示NULL，因为从属服务器不知道主服务器正在做什么，也不能有把握地说落后多少。
属性解释参考：https://blog.csdn.net/shiqidide/article/details/7263652
- 停止：stop slave 即可
至此从机配置完成。
测试数据
-
在101 主库上创建一个测试数据库：create database testMasterSlave;
图片.png
从库上面也同步了该库。
-
创建表，并插入数据：
CREATE TABLE tb_emp (
ID INT (11),
NAME VARCHAR (25),
deptId INT (11),
salary FLOAT
);
图片.png -
在100从库中 ，同步成功
图片.png 如果想指定从库从哪个位置开始同步，需要重新设定 文件位置
CHANGE MASTER TO MASTER_HOST='192.168.92.101', MASTER_USER='root', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=120;
