13518219792
在MySQL服务器1中，添加如下配置：
创新互联服务紧随时代发展步伐，进行技术革新和技术进步，经过10余年的发展和积累，已经汇集了一批资深网站策划师、设计师、专业的网站实施团队以及高素质售后服务人员，并且完全形成了一套成熟的业务流程，能够完全依照客户要求对网站进行做网站、成都网站建设、建设、维护、更新和改版，实现客户网站对外宣传展示的首要目的，并为客户企业品牌互联网化提供全面的解决方案。
在MySQL服务器2中，添加如下设置：
在这里两台MySQL的配置文件，需要对auto_increment_offset字段，设定不同值。因为如果mysql中有自增长字段，不设定这个参数会起冲突，会报duplicate....的报错。
auto_increment_offset表示自增长字段从那个数开始，他的取值范围是1 .. 65535
auto_increment_increment表示自增长字段每次递增的量，其默认值是1，取值范围是1 .. 65535
做主主同步配置时，需要将两台服务器的auto_increment_increment增长量都配置为2，而要把auto_increment_offset分别配置为1和2，这样可以避免两台服务器同时做更新时,自增长字段的值之间发生冲突。
配置好两台mysql的my.cnf配置文件后，service mysqld restart 重启mysql服务。
在Mysql服务器1中，
在MySQL服务器2中，做如上同样的操作，然后将服务器1的file和position值设定到服务器2中，服务器2的file和position值输入到服务器1中。
在MySQL服务器1中，输如下命令：
在MySQL服务器2中，输如下命令：
范例如下图：
配置完后，分别在两台服务器上输show slave status ;
如果出现如下两个字段都是on的状态，则主主备份搭建完成。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
在实际测试配置中，由于MySQL服务器2是克隆的MySQL服务器1的，所以start slave 后，show slave status 出现了Slave_IO_Running: No ,然后有如下报错信息。告知是因为两个MySQL服务器的UUID相重复了。
只需要，将basedir,即/use/local/mysql/data中的auto.cnf文件删掉后，重启mysql，就会出现新的auto.cnf文件，里面有新的UUID
MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后，在A上写数据，另外一台B也会跟着写数据，两者数据实时同步；
MySQL主从是基于binlog的，主上须开启binlog才能进行主从。
主从过程大致有3个步骤
1）主将更改操作记录到binlog里；
2）从将主的binlog事件(sql语句)同步到从本机上并记录在relaylog里；
3）从根据relaylog里面的sql语句按顺序执行；
主上有一个log dump线程，用来和从的I/O线程传递binlog
从上有两个线程，其中I/O线程用来同步主的binlog并生成relaylog，另外一个SQL线程用来把relaylog里面的sql语句落地
同步参数“主”“从”上均可设置，只要设置一个就可以了
为了保障数据的安全与稳定性，我们常用数据库的主从复制与主主复制来实现。主从复制为从机实时拷贝一份主机的数据，当主机有数据变化时，从机的数据会跟着变，当从机数据有变化时，主机数据不变；同样地，主主复制就是，多个主机之间，只要有一个主机的数据变化了，其它主机数据也会跟着变化。
添加以下内容
如果你是使用我之前那种方式启动的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（收藏！）
MySQL主主同步跟MySQL主从同步类似
只是再另一台上反向再做一次主从同步
只不过MySQL的配置文件有些地方需要注意一下
环境准备两台机器
做好优化
我这里用的 mysql-5.7.20
以都同步成功了！
下面要说的过程中遇到的问题，
实际是主从配置的扩展，例如有两台机器a1,a2,主从模式为a1（M)-a2(S),双主模式就是a1-a2,然后a2-a1
这样，当任意一台挂掉的时候，其中一台可以完全负担起读和写的任务。
**创建主节点用户供从节点拉取数据用（62-215)
同主
修改用户名密码
账号登陆
同主
(62做从节点从215拉数据的账号)
双主至此配置完成，其实就是先配置a-b,在配置b-a
注意，每次重启mysql服务以后，需要重新执行start slave命令
MySQL 主从一直是面试常客，里面的知识点虽然基础，但是能回答全的同学不多。
比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试官留下非常好的印象。你之前面试，有遇到过哪些 MySQL 主从的问题呢？
所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库， 主库对外提供读写的操作，从库对外提供读的操作 ，下面是一主一从模式：
对于数据库单机部署，在 4 核 8G 的机器上运行 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS， 当遇到一些活动时，查询流量骤然，就需要进行主从分离。
大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级，所以我们可以通过一主多从的方式， 主库只负责写入和部分核心逻辑的查询，多个从库只负责查询，提升查询性能，降低主库压力。
MySQL 主从还能做到服务高可用，当主库宕机时，从库可以切成主库，保证服务的高可用，然后主库也可以做数据的容灾备份。
整体场景总结如下：
MySQL 的主从复制是依赖于 binlog 的，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。
主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的操作不会等待 binlog 同步的完成。
详细流程如下：
当主库和从库数据同步时，突然中断怎么办？因为主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。
对于下面的情况，假如主库执行如下 SQL，其中 a 和 create_time 都是索引：
我们知道，数据选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。
所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条 SQL 时，使用的是索引 a，而从库在执行这条 SQL 时，使用了索引 create_time，最后主从数据不一致了。
那么我们改如何解决呢？
可以把 binlog 格式修改为 row，row 格式的 binlog 日志记录的不是 SQL 原文，而是两个 event:Table_map 和 Delete_rows。
Table_map event 说明要操作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。 row 格式的 binlog 记录的就是要删除的主键 ID 信息，因此不会出现主从不一致的问题。
但是如果 SQL 删除 10 万行数据，使用 row 格式就会很占空间的，10 万条数据都在 binlog 里面，写 binlog 的时候也很耗 IO。但是 statement 格式的 binlog 可能会导致数据不一致。
设计 MySQL 的大叔想了一个折中的方案，mixed 格式的 binlog，其实就是 row 和 statement 格式混合使用， 当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。
有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。
主从延迟，其实就是“从库回放” 完成的时间，与 “主库写 binlog” 完成时间的差值， 会导致从库查询的数据，和主库的不一致 。
谈到 MySQL 数据库主从同步延迟原理，得从 MySQL 的主从复制原理说起：
总结一下主从延迟的主要原因 ：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。
我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落后的时间达到了秒级别就需要告警了。
解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。
具体解决方案如下：
在实际应用场景中，对于一些非常核心的场景，比如库存，支付订单等，需要直接查询从库，其它非核心场景，就不要去查主库了。
两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。
如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。
一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。
如果 A 库发生故障，B 库成为主库负责读写，C、D负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。
