mysql主从理解和配置

二进制日志(bin-log)的说明——主从的前提

bin-log的相关字段和文件说明

查看日志日否开启等信息情况

• log_bin：是否开启
• log_bin_basename：二进制日志文件名字(实际情况下会在后面加上.索引来命名文件)
• log_bin_index：记录日志文件的索引文件

查看准作为主从中的主库的信息。

• File：当前使用的二进制日志的文件和索引
• Possition：当前日志运行到那个点了

对应的二进制日志文件和索引文件的关系。

注意：每次mysql重启都会重新开启一个mysql-bin.*日志文件。长期不重启mysql-bin文件会过大。还是请dba来处理文件过大问题吧/(ㄒoㄒ)/~~。

如何查看文件内容

方法1：mysqlbinlog命令查看

mysqlbinlog 命令，以用户可视的方式展示出二进制日志中的内容。同时，也可以将其中的内容读取出来，供其他MySQL实用程序使用。

为了方便，我们将mysql其他相关命令加入到系统命令行中。不需要或已经懂的直接跳过。

查看日志
[root@MiWiFi-R3P-srv data]# mysqlbinlog ./mysql-bin.000006

方法2：show binlog events命令查看

show binlog events 命令查看某个binlog日志内容。

命令：

mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

选项解析：

  IN 'log_name' 指定要查询的binlog文件名(不指定就是第一个binlog文件)
  FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
  LIMIT [offset,] 偏移量(不指定就是0)
  row_count 查询总条数(不指定就是所有行)

实例：

A.查询第一个(最早)的binlog日志：
  mysql> show binlog events\G; 

B.指定查询 mysql-bin.000021 这个文件：
  mysql> show binlog events in 'mysql-bin.000021'\G;

C.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起：
  mysql> show binlog events in 'mysql-bin.000021' from 8224\G;

D.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，查询10条
  mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 10\G;

E.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，偏移2行，查询10条
  mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 2,10\G;

实操截图

[root@MiWiFi-R3P-srv data]# mysqlbinlog mysql-bin.000001 --start-position 3078 --stop-position 4413 | mysql -u root -p     

主从配置

master(1)-slave(1)实现过程

1.开启主库的binlog

在主库的mysql中:

2.主库中配置复制账号和账号的权限

主库中创建复制账号和分配账号权限

在从库中连接测试

4.配置从库配置文件

在从库中配置

5.启动复制

在从库中执行：

# 参数说明
master_host：# master ip
master_port: # master 端口号
master_user: # 连接主库的用户名
master_password: # 连接主库的密码
master_log_file: # 启动是开始读取的二进制日志
master_log_pos: # 打算从主库开始复制的日志节点，对应日志文件中的position

# 执行语句
change master to
master_host='192.168.153.129',
master_port=3306,
master_user='slave_user',
master_password='slave_pwd',
master_log_file='mysql-bin.000001',
master_log_pos=0;

# 启动从节点
start slave;

# 停止从节点
stop slave;

# 清除slave信息(配置有误的时候用)
reset slave;

验证从库是否启动正常(在从库中执行）：

show slave status\G

# 主要看字段信息
slave_io_running：表示异步连接主库进行binlog同步的IO是否正常
slave_sql_running：表示中继日志文件同步到磁盘是否正常

Last_IO_Errno: 对应slave_io_running错误的错误码
Last_IO_Error: 对应slave_io_running错误的错误信息
Last_SQL_Errno: 对应slave_sql_running错误的错误码
Last_SQL_Error: 对应slave_sql_running错误的错误信息

关于slave_io_running和slave_sql_running图片解释(来自于某视频)

相关报错:

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.

data目录中有auto.cnf文件 这个和原来的克隆过来冲突，将该文件删除重启就好了

6.检查结果

在主库和从库分别执行查看对应的库和表数据。


在主库中执行sql操作语句

insert into user(name) value('李四');

在从库中进行检验

select * from user;

检验成功！！！

logs-slave-updates的参数说明

logs-slave-updates 参数主要在多主多从的集群架构中开启，否则会导致各从实例无法完整同步集群的全量数据的问题。

多主多从集群架构：
masterA → slaveA
↑ ↓
masterB → slaveB

logs-slave-updates：Normally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log.

即，正常情况下，一个slave节点是不会将其从master节点同步的数据更新操作记录至自己的二进制日志bin-log中的。

在多主的场景下，各master节点其实又相互作为另一方的slave节点进行着数据的一致性同步操作。例如 masterA 会以slave的角色同步 masterB 上的数据，masterB 也会以slave的角色同步 masterA 上的数据，如果没有开启 logs-slave-updates参数配置，则masterA masterB 虽然也能保证数据的一致性和完整性，但二者的 bin-log 中都只记录了作用在自身实例上的数据更新操作。