2019/04/25 主从级联复制和主主模型

mysqldump适用于较小的数据量
大量数据，就需要xtrabackup，复制的时候是基于数据块的机制，而不是数据库本身去进行一个大的查询，相对效率较高
主从复制，要求我们一个先 要是主，有一些必要的设置是必须启用的，
必须在主服务器上开启二进制日志，（是因为mysql主从是依赖于二进制日志的，需要利用mysql二进制在主服务器上复制到远程的从服务器上去，在复制的时候用到了相关的线程，
第一个线程在主服务器上 叫dump threaddump线程，在dump线程上去启用，启用了以后会把二进制日志利用dump线程通过tcp网络复制到从服务器上去，而从服务器那里也需要开启一个线程，这个线程来接受从主服务器上复制过来的二进制日志，叫IO线程
IO线程接受以后，需要落地，需要放到从服务器上某一个地方，存起来，可以存放到中继日志relay-log，把这个日志存到中继日志以后，
目标还是把二进制日志恢复到从数据库里，因此又用到了一个线程，叫sql thread，这个线程就是读取中继日志里（relay-log）的内容，把它应用在我们的数据库中）
但是如果在从服务器上启用二进制日志，（从服务器上是不一定要启用二进制日志），如果启用，
能否看到从主服务器上来的数据的变化，二进制是记录的数据库变化，，但是在从服务器上是不记录从主服务器复制过来的数据的，记录的是，除非你在服务器上增删改（直接在从服务器上增删改，才会记录在从服务器上，一般从服务器是只读的，这样的事情一般不会发生，read-only，从服务器的数据库是不能被普通用户直接去写操作的）
在生产中一个主带一个从，一主带多从是应用广泛的（但是，主服务器本身压力很大，如果用户大量的写操作请求，用到主服务器上，主服务器不仅要负责写，还要承担复制的功能，就要把自己的更新利用dump线程发送给各个从，有多少个从，就要开启多少个线程，无形中对主服务器的压力是比较偏大的，为了降低主服务器的压力，可以考虑建立一个级联复制）

如何来实现一个中间的级联设备，如何把一个从服务器从主服务器复制来的二进制日志记录到自己的二进制日志文件里，需要额外加一个设置

这个设置就是log_slave_updates，只有添加这个选项，才能让从服务器接收别的从服务器的传输

如何搭建一个级联复制，三台主机，7,17,27
先建立一个主服务器

版本不同，互相复制可能存在问题，所以建议尽量用相同的版本
之前是编译安装，都需要删除

path变量删除，my.cnf配置文件是来自mysql-lib这个包里的


lib包里有一个etc文件



看下日志有什么提示


端口被占了

查看17是否是干净系统


都把数据库清了，7当主


这个主服务器就初步搭建好了
还需要创建账号授权
主服务器哪天坏了，需要提升一个从服务器作为主服务器，就需要实现把账号复制过去，也是合理的


再另外搭建中间的从服务器（也是一个主）
log_slave_updates 是记录从主服务器上过来的更新，写到当前自己的二进制日志里，如果没有这个设置是写不到二进制日志里的，就没有办法复制相关的二进制数据了

加个read-only会不会影响复制

这个是中间的级联复制服务器，成功之后在进行后面的从服务器设置操作



先要作为一个正常的从，需要change master to




还没有开始复制，已经生成了中继日志，里面还没有内容，还没有真正的复制

需要清掉备份删除下来的日志


开始生成，这样就有中继日志了


查看复制过来没有


查看级联服务器同步的信息


读主服务器的位置，中继日志的位置

执行的位置，和读的位置不太一样，这个读就是从主服务器上把二进制日志传到relay里去，但是正常应用到系统里中间还有时间差，有一定的延迟，那边生成数据结束以后，两边也就没什么延迟了

二进制日志也增长了


想把刚才的信息删除，从头复制
把slave的一些信息删除，先要停止，才能删除

就把relaylog清理了，master。info也没有了，意味着就不知道从哪里复制了

清除了，下次启动之后还会复制吗
但是这边还保留了一些信息，需要彻底清除

这个功能就适合发现错误，不想复制了，需要从头复制,其实刚才是已经复制成功的

假设想要从头来
删除数据库，重新搭建

但是配置文件没改


现在要从头复制的话还是需要从四百复制的

添加复制信息

就需要开启，进行复制

延迟多少秒

不过一般生产数据庞大，都是先要数据备份

接下里配置第三个服务器

安装数据库


在主服务器建了个账号，这个行号在中间的服务器是否存在

我们是先创建再差，所以就没有账号、所以只能在手工在中间服务器上创建了

数据在刚刚开始的时候都是245；


开始复制

链接上 了

已经有数据了

对于级联复制，我们read-only加上去不受影响
在中间的级联服务器，你是管理员可以创建和修改
read-only只针对普通用户有效

这个数据库就复制到了37上了，主服务器是没有的，因为是在中间机器上做的事情


假如其中的一个从成为主，新的主的主服务器，就需要把刚才的从服务器上面的信息修改掉，指定新的端口，主机名，用户

这种方法是错误的，是针对所有的主机，包括主服务器复制也进不去了


查看官方描述

默认是0，就是操作系统决定什么时候写到磁盘里，默认先写到buffer里，计算机找一个空闲的时候，写到磁盘里
1是只要你有写操作，就立即写到磁盘上


既是个选项也是个变量，默认1自动提交，0是不做事情，一秒执行一次，（但是一秒钟崩溃了，会丢失一些数据）
2是每一次提交都写，（先把事务日志放到buffer里，buffer在内存中，buffer写完里以后，写到磁盘里，一秒写一次，性能是相对不错的，但是电力问题崩溃就丢失最后一秒数据了），从服务器和主服务器之间是基于串行的机制，所以天生就决定了在主从复制中间造成了一些延迟

在进行复制的时候往往延迟特别长，多个并行变成一个串行，甚至达一个小时之久，是因为天生的这样的一种机制
所以我们尽可能做些优化，减少性能过载，可以改成2，立即写（但是有可能出现错误，丢失一部分数据）


记录目前同步到哪了

有多个从，主服务器要是坏了，从服务器不会都在一个点上，如果要找新的从变成主，那就需要找最新的
现在27,37都在做为17 从

生成的日志都清了，但是数据库还在，是不会清除的

查看17 的日子位置

37切换下日志，开启同步

数据已经复制过来了

新的master记录新的主服务器数据

relay-log执行到哪了

开始加数据

这两个从服务器并不能完全同时同步，如果现在把主服务器停了，两个服务器就有可能同步不一致

27复制进度

37复制进度也一样，因为没什么负载

17的主服务器现在这么多条记录

从服务器27也这么多

17主服务器再去执行，看看日志大小不一样，从服务器能否同步

未进行同步

由于主服务器文件位置，所以就始终无法同步

停了重开查看是否生效
未同步，说明出现问题

报错s，认为这个位置是不存在的

**也可以把主的备份过来，从头开始复制，(需要先把从服务器数据文件清除，但是数据库内容已经有了，是否全部删除，
**
需要从头复制

开启复制线程


有可能就断电造成二进制文件破坏了
但是数据还在，就可以重新来过,先给mysql做下备份
从新的开始，早期的日志就干掉了

复制备份到从服务器

从服务器再重新清理一下，准备还原


导入备份文件

启动，查看状态

两边应该是同步的
在主上创建一个数据库试试

从服务器复制过来了

以前的二进制就没有用了，如何删除


这样磁盘上就没有哪个文件了

现在二进制就剩一个了

上面就是主从复制以及一些基本问题
如果不想自动启动线程，就可以用skip_slave_start=on

日志写多少次，写到磁盘上

另外就是主主复制，同时都可以对外进行写操作，如果别人添加一个主键，另外一个用户同时也在另外一个主机上插入相同主键，这样就冲突了，为了避免这个情况，就需要配置，奇偶数ID

auto_increment编号自动生长，左边第一台机器是1开始，每个涨2，另一个开始点是2，每个涨2

现在来实现主主，恢复环境


如果是三个主服务器

在27上也需要设置，并且重新启动服务

如果不是干净系统，就还牵涉到备份数据库还原的问题
双方都需要和对方同步，就都需要先创建账号

在另外一个服务器上开启复制

开始同步

这边405说明已经把账号同步过来了


账号过来了，说明自己不用创建账号了，然后需要在17那边重新执行同步的命令

主服务器的二进制日志和复制的二进制日志没有关系，复制过来的数据，在你数据库上应用是不会生成二进制的日志的


开启复制，查看状态

测试两边是否能同步

17创建数据库

27能够同步

27创建数据库

17也同步过来了

就怕添加相同的表



有个auto_increment，由于是同步过来的，现在还没有问题

如果在表中添加记录

同样的事情，在27上也执行

昨天17这个机器一直用的奇数，27一直用的偶数

如果加多条记录


以此来避免id冲突，这个只是解决auto_increment问题
如果非要选择加奇数，会如何

强行指定，也是可以加的，加这两个选项就是为了避免冲突的问题，但是也是有可能两边同时加29，就有可能产生数据不一致的问题，mysql是无能为力的，所以主主一般很少用
oracle(有双主，但是文件时共享的）集群环境有共享的磁盘存储 的，真正写磁盘是放到一个磁盘上的