mysql主从复制三种模式

mysql主从复制三种模式：

1、异步复制：主服务器将执行的事务发送到从服务器，不等待从服务器的响应，主服务器只是将事务发送出去；

2、半同步复制：主服务器会等待从服务器的响应，当主服务器收到从服务器的响应后，才继续执行下一个事务；

3、同步复制：主服务器会等待从服务器的响应，主服务器将事务发送到从服务器后，必须等待从服务器的响应，从服务器确认收到事务后，主服务器才能继续执行下一个事务。

拓展：MySQL主从复制模式可以实现数据备份、提高服务器性能、实现数据安全等功能，是MySQL数据库系统中常用的一种复制方式。

为了保障数据的安全与稳定性，我们常用数据库的主从复制与主主复制来实现。主从复制为从机实时拷贝一份主机的数据，当主机有数据变化时，从机的数据会跟着变，当从机数据有变化时，主机数据不变；同样地，主主复制就是，多个主机之间，只要有一个主机的数据变化了，其它主机数据也会跟着变化。

添加以下内容

如果你是使用我之前那种方式启动的MySQL，那么你只需要去你相关联的宿主机的配置文件夹里面去建立一个 my.cnf 然后写入上面的类容就好了。

比如：我的启动命令如下（不应该换行的，这里为了方便查看，我给它分行了）

那么我只需要在 /docker/mysql_master/conf 这个目录下创建 my.cnf 文件就好了。

这个命令是需要在容器里面执行的

docker重启mysql会关闭容器，我们需要重启容器。

确保在主服务器上 skip_networking 选项处于 OFF 关闭状态, 这是默认值。 如果是启用的，则从站无法与主站通信，并且复制失败。

我的命令如下

在从服务器配置连接到主服务器的相关信息 （在容器里面的mysql执行）

上面代码的xxxxx你需要换成你的IP，docker 查看容器 IP 的命令如下：

启动的那个从服务器的线程

测试的话，你可以在主服务器里面，创建一个数据库，发现从服务器里面也有了，就成功了。

如果你还想要一个从服务器，那么你只需要按照上面配置从服务器再配置一个就行了，新建的从服务器，会自动保存主服务器之前的数据。（测试结果） 如果你上面的主从复制搞定了，那么这个主主复制就很简单了。我们把上面的从服务器也改成主服务器

1）、修改上面的从服务器的my.cnf文件，和主服务器的一样（注意这个server-id不能一样）然后重启服务器 2）、在从服务器里面创建一个复制用户创建命令一样（这里修改一下用户名可以改为 repl2） 3）、在之前的主服务器里面运行下面这个代码

上面主要是教你怎么搭建一个MySQL集群，但是这里面还有很多其它的问题。也是我在学习过程中思考的问题，可能有的小伙伴上来看到文章长篇大论的看不下去，只想去实现这样一直集群功能，所以我就把问题写在下面了。

1）、MySQL的replication和pxc MySQL的集群方案有replication和pxc两种，上面是基于replication实现的。

replication: 异步复制，速度快，无法保证数据的一致性。 pxc: 同步复制，速度慢，多个集群之间是事务提交的数据一致性强。

2）、MySQL的replication数据同步的原理 我们在配置的时候开启了它的二进制日志，每次 *** 作数据库的时候都会更新到这个日志里面去。主从通过同步这个日志来保证数据的一致性。

3）、可否不同步全部的数据 可以配置，同步哪些数据库，甚至是哪些表。

4）、怎么关闭和开始同步

5）、我就我的理解画出了，主从、主从从、主主、复制的图。

往期推荐：

利用Docker仅花1分钟时间安装好MySQL服务

Linux下MySQL 5.7的离线与在线安装（图文）

Linux下安装MySQL8.0（收藏！）

大致流程：主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个中继日志 relay日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL，这样就可以保证自己跟主库的数据是一样的。

如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，这时候从库成为了主库，那么有些数据可能就丢失了。

开启半同步复制 semi-sync ，用来解决主库数据丢失问题；

这个所谓半同步复制， semi-sync复制 ，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志 写入自己本地的relay log之后 ，接着会 返回一个ack 给主库， 主库接收到至少一个从库的ack之后才会认为写 *** 作完成了。 如果 过程出现失败 ，那么 我们的客户端就可以进行重试了 ；

主从延迟对于读写分离的涉及影响比较大

这里有一个非常重要的一点，就是 从库同步主库数据的过程是串行化的 ，也就是说 主库上并行的 *** 作，在从库上会串行执行 。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在 高并发场景下，主库大量的写，那么从库的数据一个个的读，那么就会导致从库同步一定会比主库慢一些，是有延时的 。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。（主库并发写的量级越高，从库积压的同步数据越多，延迟越高）

我们可以用 show status 看看 Seconds_Behind_Master 参数，你可以看到从库复制主库的数据落后了几ms，但是这个也不是完全准确，可以看 Seconds_Behind_Master的

对于解决主从延迟，解决方案可以从以下方面考虑

---