MySQL主从数据不一致，需要重新关联

1. 在有主键或者唯一键的情况下，Slave 重放 Binlog 并不会去比较检索到的记录的每一列是否和BI相同，因此如果 Slave 和 Master 存在数据不一致，会直接覆盖 Slave 的数据而不会报错。

2. 在没有主键或者唯一键的情况下，Hash Scan / Hash Scan Over Index 的执行效率 在理论上分析高于 Table Scan 和Index Scan 。

3. 在没有主键或者唯一键的情况下，Slave 选择的二级索引是第一个所有的列都在 BI 中存在的索引，不一定是 Master 执行计划所选择的索引。

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

添加以下内容

如果你是使用我之前那种方式启动的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 还原 SQL 备份经常会碰到一个错误如下，且通常出现在导入视图、函数、存储过程、事件等对象时，其根本原因就是因为导入时所用账号并不具有SUPER 权限，所以无法创建其他账号的所属对象。ERROR 1227 (42000) : Access deniedyou need (at least one of) the SUPER privilege(s) for this operation常见场景：1. 还原 RDS 时经常出现，因为 RDS 不提供 SUPER 权限；2. 由开发库还原到项目现场，账号权限等有所不同。

处理方式：

1. 在原库中批量修改对象所有者为导入账号或修改 SQL SECURITY 为 Invoker；2. 使用 mysqldump 导出备份，然后将 SQL 文件中的对象所有者替换为导入账号。

二、问题原因我们先来看下为啥会出现这个报错，那就得说下 MySQL 中一个很特别的权限控制机制，像视图、函数、存储过程、触发器等这些数据对象会存在一个 DEFINER 和一个 SQL SECURITY 的属性，如下所示：

--视图定义CREATE ALGORITHM = UNDEFINED DEFINER = `root`@`%` SQL SECURITY DEFINER VIEW v_test

--函数定义CREATE DEFINER=`root`@`%` FUNCTION `f_test()` RETURNS varchar(100) SQL SECURITY DEFINER

--存储过程定义CREATE DEFINER=`root`@`%` PROCEDURE `p_test`() SQL SECURITY DEFINER

--触发器定义CREATE DEFINER=`root`@`%` trigger t_test

--事件定义CREATE DEFINER=`root`@`%` EVENT `e_test`

DEFINER：对象定义者，在创建对象时可以手动指定用户，不指定的话默认为当前连接用户；

SQL SECURITY：指明以谁的权限来执行该对象，有两个选项，一个为 DEFINER，一个为 INVOKER，默认情况下系统指定为 DEFINER；DEFINER：表示按定义者的权限来执行； INVOKER：表示按调用者的权限来执行。

如果导入账号具有 SUPER 权限，即使对象的所有者账号不存在，也可以导入成功，但是在查询对象时，如果对象的 SQL SECURITY 为 DEFINER，则会报账号不存在的报错。ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist

三、改写内容上述这个 DEFINER 问题，个人想到最简单的解决方式就是 mysqldump 导出时直接摘除掉相关属性，但是 mysqldump 本身并不提供对应参数，所以比较蛋疼，无论是原库走脚本变更或是备份后修改 SQL 文件都不是非常方便，尤其是触发器的 DEFINER，只能先 DROP 再 CREATE 才可以变更。只能看下是否可以从 mysqldump 源码中去掉 DEFINER 定义。本次 mysqldump 改写主要有 2 个目的：1. 摘取备份中视图、函数、存储过程、触发器等对象的 DEFINER 定义；2. 尝试加上比较简单的备份进度显示（原生 mysqldump 的 verbose 参数不是非常清晰，想要实现 navicate 备份时的那种行数显示）。

改写好处：1. 可以避免还原时遇到 DEFINER 报错相关问题；2. 根据输出信息知道备份是否正常进行，防止备份中遇到元数据锁无法获取然后一直卡住的情况。

---