docker部署mysql链接可参考以下链接，本文主要记录主从机配置

[1]
Docker安装mysql8-超详细、每步都有截图
 
[2]
Docker下搭建MySql主从复制

主从架构搭建

1.准备工作

2.主机配置文件

必选

1
2
3
4
5
#[必须]主服务器唯一ID
server-id= 1

#[必须]启用二进制日志,指名路径。比如：自己本地的路径/log/mysqlbin
log-bin=atguigu-bin

可选

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#[可选] 0（默认）表示读写（主机）， 1 表示只读（从机）
read-only= 0

#设置日志文件保留的时长，单位是秒
binlog_expire_logs_seconds= 6000

#控制单个二进制日志大小。此参数的最大和默认值是1GB
max_binlog_size=200M

#[可选]设置不要复制的数据库
binlog-ignore-db=test

#[可选]设置需要复制的数据库,默认全部记录。比如：binlog-do-db=atguigu_master_slave
binlog-do-db=需要复制的主数据库名字

#[可选]设置binlog格式
binlog_format=STATEMENT

binlog格式设置

格式 1 ：STATEMENT模式（基于SQL语句的复制(statement-based replication, SBR)

1
binlog_format=STATEMENT

每一条会修改数据的sql语句会记录到binlog中。这是默认的binlog格式。

  • SBR 的优点：

    • 历史悠久，技术成熟

    • 不需要记录每一行的变化，减少了binlog日志量，文件较小

    • binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况

    • binlog可以用于实时的还原，而不仅仅用于复制

    • 主从版本可以不一样，从服务器版本可以比主服务器版本高

  • SBR 的缺点：

    • 不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候

    • 使用以下函数的语句也无法被复制：LOAD_FILE()、UUID()、USER()、FOUND_ROWS()、SYSDATE()(除非启动时启用了 --sysdate-is-now 选项)

    • INSERT … SELECT 会产生比 RBR 更多的行级锁

    • 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁

    • 对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句

    • 对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响

    • 执行复杂语句如果出错的话，会消耗更多资源

    • 数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错

格式 2：ROW模式（基于行的复制(row-based replication, RBR)

1
binlog_format=ROW

5.1.5版本的MySQL才开始支持，不记录每条sql语句的上下文信息，仅记录哪条数据被修改了，修改成什么样了。

  • RBR 的优点：

    • 任何情况都可以被复制，这对复制来说是最安全可靠的。（比如：不会出现某些特定情况下的存储过程、function、trigger的调用和触发无法被正确复制的问题）

    • 多数情况下，从服务器上的表如果有主键的话，复制就会快了很多

    • 复制以下几种语句时的行锁更少：INSERT … SELECT、包含 AUTO_INCREMENT 字段的 INSERT、没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句

    • 执行 INSERT，UPDATE，DELETE 语句时锁更少

    • 从服务器上采用多线程来执行复制成为可能

  • RBR 的缺点：

    • binlog 大了很多

    • 复杂的回滚时 binlog 中会包含大量的数据

    • 主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题

    • 无法从 binlog 中看到都复制了些什么语句

格式 3：MIXED模式（混合模式复制(mixed-based replication, MBR)

1
binlog_format=MIXED

从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。

在Mixed模式下，一般的语句修改使用statment格式保存binlog。如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog。

MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

3.从机配置文件

必选

1
2
#[必须]从服务器唯一ID  
server-id= 2

可选

1
2
#[可选]启用中继日志  
relay-log=mysql-relay

4.主机：建立账户并授权

MySQL8，需要如下的方式建立账户，并授权slave：

1
2
3
4
5
6
CREATE USER 'slave1'@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE ON *.* TO 'slave1'@'%';

ALTER USER 'slave1'@'%' IDENTIFIED WITH mysql_native_password BY '123456';

flush privileges;

查询Master的状态，并记录下File和Position的值。

1
show master status;

5.从机：配置需要复制的主机

步骤 1 ： 从机上复制主机的命令

1
2
3
4
5
6
7
CHANGE MASTER TO
MASTER_HOST='主机的IP地址',
master_port=端口号,
MASTER_USER='主机用户名',
MASTER_PASSWORD='主机用户名的密码',
MASTER_LOG_FILE='mysql-bin.具体数字',
MASTER_LOG_POS=具体值;


步骤 2 ：

1
2
#启动slave同步
START SLAVE;

如果报错：

可以执行如下操作，删除之前的relay_log信息。然后重新执行 CHANGE MASTER TO …语句即可。

1
mysql> reset slave; #删除SLAVE数据库的relaylog日志文件，并重新启用新的relaylog文件
1
SHOW SLAVE STATUS\G; # 查看同步状态

显式如下的情况，就是不正确的。可能错误的原因有：

  1. 网络不通

  2. 账户密码错误

  3. 防火墙

  4. mysql配置文件问题

  5. 连接服务器时语法

  6. 主服务器mysql权限

6.停止主从同步

停止主从同步命令：

1
stop slave;

如何重新配置主从
如果停止从服务器复制功能，再使用需要重新配置主从。否则会报错如下：

重新配置主从，需要在从机上执行：

1
2
3
stop slave;

reset master; #删除Master中所有的binglog文件，并将日志索引文件清空，重新开始所有新的日志文件(慎用)

7.同步数据一致性问题

主从同步的要求：

  • 读库和写库的数据一致(最终一致)；

  • 写数据必须写到写库；

  • 读数据必须到读库(不一定)；

7. 1 理解主从延迟问题

进行主从同步的内容是二进制日志，它是一个文件，在进行网络传输的过程中就一定会存在主从延迟（比如 500 ms），这样就可能造成用户在从库上读取的数据不是最新的数据，也就是主从同步中的数据不一致性问题。

举例:导致主从延迟的时间点主要包括以下三个:

1.主库A执行完成一个事务，写入binlog，我们把这个时刻记为T1;

2之后传给从库B，我们把从库B接收完这个binlog的时刻记为T2;

3．从库B执行完成这个事务，我们把这个时刻记为T3。

7. 2 主从延迟问题原因

在网络正常的时候，日志从主库传给从库所需的时间是很短的，即T 2 - T 1 的值是非常小的。即，网络正常情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。

主备延迟最直接的表现是，从库消费中继日志（relay log）的速度，比主库生产binlog的速度要慢。 造成原因：

1 、从库的机器性能比主库要差

2 、从库的压力大

3 、大事务的执行

举例 1 ： 一次性用delete语句删除太多数据

结论：后续再删除数据的时候，要控制每个事务删除的数据量，分成多次删除。

举例 2 ： 一次性用insert…select插入太多数据

举例: 3 ： 大表DDL

比如在主库对一张500W的表添加一个字段耗费了 10 分钟，那么从节点上也会耗费 10 分钟。

7. 3 如何减少主从延迟

若想要减少主从延迟的时间，可以采取下面的办法：

  1. 降低多线程大事务并发的概率，优化业务逻辑

  2. 优化SQL，避免慢SQL，减少批量操作，建议写脚本以update-sleep这样的形式完成。

  3. 提高从库机器的配置，减少主库写binlog和从库读binlog的效率差。

  4. 尽量采用短的链路，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输的网络延时。

  5. 实时性要求的业务读强制走主库，从库只做灾备，备份。

7. 4 如何解决一致性问题

如果操作的数据存储在同一个数据库中，那么对数据进行更新的时候，可以对记录加写锁，这样在读取的时候就不会发生数据不一致的情况。但这时从库的作用就是备份，并没有起到读写分离，分担主库读压力的作用。

读写分离情况下，解决主从同步中数据不一致的问题， 就是解决主从之间数据复制方式的问题，如果按照数据一致性从弱到强来进行划分，有以下 3 种复制方式。

方法 1 ：异步复制

异步模式就是客户端提交COMMIT之后不需要等从库返回任何结果，而是直接将结果返回给客户端，这样做的好处是不会影响主库写的效率，但可能会存在主库宕机，而Binlog还没有同步到从库的情况，也就是此时的主库和从库数据不一致。这时候从从库中选择一个作为新主，那么新主则可能缺少原来主服务器中已提交的事务。所以，这种复制模式下的数据一致性是最弱的。

方法 2 ：半同步复制

MySQL5.5版本之后开始支持半同步复制的方式。原理是在客户端提交COMMIT之后不直接将结果返回给客户端，而是等待至少有一个从库接收到了Binlog，并且写入到中继日志中，再返回给客户端。

这样做的好处就是提高了数据的一致性，当然相比于异步复制来说，至少多增加了一个网络连接的延迟，降低了主库写的效率。

在MySQL5.7版本中还增加了一个rpl_semi_sync_master_wait_for_slave_count参数，可以对应答的从库数量进行设置，默认为1，也就是说只要有1个从库进行了响应，就可以返回给客户端。如果将这个参数调大，可以提升数据一致性的强度，但也会增加主库等待从库响应的时间。

方法 3 ：组复制

异步复制和半同步复制都无法最终保证数据的一致性问题，半同步复制是通过判断从库响应的个数来决定是否返回给客户端，虽然数据一致性相比于异步复制有提升，但仍然无法满足对数据一致性要求高的场景，比如金融领域。MGR 很好地弥补了这两种复制模式的不足。

组复制技术，简称 MGR（MySQL Group Replication）。是 MySQL 在 5.7.17 版本中推出的一种新的数据复制技术，这种复制技术是基于 Paxos 协议的状态机复制。

MGR 是如何工作的

首先我们将多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层 （Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应 Node 节 点）的同意，大多数指的是同意的节点数量需要大于 （N/2+1），这样才可以进行提交，而不是原发起 方一个说了算。而针对只读（RO）事务则不需要经过组内同意，直接 COMMIT 即可。

在一个复制组内有多个节点组成，它们各自维护了自己的数据副本，并且在一致性协议层实现了原子消息和全局有序消息，从而保证组内数据的一致性。

MGR 将 MySQL 带入了数据强一致性的时代，是一个划时代的创新，其中一个重要的原因就是MGR 是基 于 Paxos 协议的。Paxos 算法是由 2013 年的图灵奖获得者 Leslie Lamport 于 1990 年提出的，有关这个算 法的决策机制可以搜一下。事实上，Paxos 算法提出来之后就作为分布式一致性算法被广泛应用，比如 Apache 的 ZooKeeper 也是基于 Paxos 实现的。