第1节. 主从服务故障恢复和级联复制

半途做主从

一半业务刚起步也不会做什么主从，就单机，随着业务体量起来才会考虑架构的事情。所以需要处理主从复制的时候主节点上已经有很多数据的情况。

思路就是：先将主节点的数据备份-还原到从节点--其实如果是VM直接克隆出来一台就行了连mysqldump都不需要，再开启主从复制，复制的位置就是show master logs的位置。

实验一下

1、弄一个干净的mariadb服务

image-20230807154933945

然后这里报错，就是文件夹的权限问题

image-20230807155538276

binlog就有了

image-20230807155608622

2、制造一些数据，代表单节点的数据起来了--我认为因该要做这个

image-20230807173219240

image-20230807174240624

image-20230807174307863

image-20230807172556118

然后备份，还原一下，这里就不偷懒用VM克隆，实际工作中反而是克隆直接，不过具体情况具体看咯，两种方法都得会。


主节点的账号要不要复制过去给从节点，要！主从复制本身从节点上不用有账号库，但是从节点万一成为了主节点，此时其他的从节点就会和这个提升上来的从节点上同步数据，此时该节点就需要有同步用的账号库了。这就是考虑问题的时间跨度要有，所以当面临一个不擅长的问题，就需要有这个时间跨度的意识去拉自己一把。

所以做主从的时候，就是先创建账号，再备份还原过去，这样账号就一起还原到从节点了。

3、有了一些数据了，也先于主从复制创建了账号。现在还是备份使用mysqldump

image-20230807175924141

image-20230808092416558

关键语句如下👇

image-20230808092532397

这条语句其实就是主从复制的，从节点上面用的复制配置CLI。

image-20230808092926951

msyqldump里的--master-data=1这个=1就是在从节点上面还原的时候直接顺带执行了change master to xxxx 了，不过还缺一个mater的IP是多少。

所以直接在从节点执行也是不行的。还得补齐master的IP，复制的账号。

4、将dump出来的备份复制到从节点

image-20230808093408833

image-20230808093420643

将从节点的mariadb 删库，卸载，重装，发现，/etc/my.cnf会自动给你备份，新建，还是挺不错的。

image-20230808093944660

重新安装好mariadb后，不要启用服务，否则会自动生成/var/lib/mysql/的一些文件，这样不利于还原主节点那边的数据。 # 当然这视频里说的，现在版本又不这么回事了，yum install后，直接/var/lib/mysql/下就会直接生成文件，不用启动也会又文件初始化生成的。所以不用管这些。而且你恢复dump文件的时候就是要先启动服务的。

然后vim 进去备份文件all.sql补全从节点的change maser to的相关信息

image-20230808094805818

5、修改从节点的配置文件

image-20230808095203040

6、恢复dump文件

启动服务

image-20230808095352697

image-20230808095416588

image-20230808095442495

db也是默认的几个，slave status也是空的

serverid没问题，注意是下划线。/etc/my.cnf里面可以-可以\，但是mysql交互模式进来就是变量去看，变量就是_。

image-20230808095644769

image-20230808095857966

但是这个read_only ON是防不住root的哦，root依然可以修改的。

由于vim过all.sql补齐了change master to的相关信息，所以可以直接mysql < all.sql还原并直接置为从节点，如果在交互模式里直接source /data/all.sql就行

image-20230808100053537

image-20230808100535716

此时从节点的配置好了，就差一个启动

image-20230808100137111

然后此时一些 relay文件就生成了

image-20230808100346137

目前没有启动，从节点和master节点的网络连接还没有

image-20230808100423876

待会启动了slave start后，从节点就会主动连接主节点的3306端口去了。

image-20230808101310667

然后就报错鸟

image-20230808101438741

不过由于IO thread起来了，所以ss -nt tcp连接时已经建立

image-20230808101511123

然后拍个错

这对这个报错

image-20230808103112143

flush priveleges；就行了，然后start slave；一下。

然后就发现继续报错

image-20230808103133827

我只能说FUCK，然后我继续排错，过程嘛就是remove \install \remove\install，

发现了一个all.sql这个dump文件里的错误，就是分号

image-20230808105440935

好像就是这个原因，我再改回分号试试，破案了，就是这个分号导致了上面的start slave后的show slave stauts\G看到的报错，而且细究一下其实mysql < /data/all.sql是会报错的，👇如图

image-20230808115243980

但是你要是进入mysql，敲source /data/all.sql，就看不到报错了，所以由此看来，还是建议在外面做mysql < /data/all.sql的还原操作比较OK。

image-20230808142540876

👆应该root不受限，所以可以导入了

总之就是

  yum -y remove mariadb-server
  rm -rf /var/lib/mysql/*
  yum -y install  mariadb-server
  \cp -a /etc/my.cnf.rpmsave /etc/my.cnf
  systemctl start mariadb
  systemctl status mariadb
  mysql < /data/all.sql
这样就可以啦

image-20230808135650595

OK了

tcp 建连也没问题

image-20230808135717742

数据也还原的没问题

image-20230808140010490

然后看看主从复制是否OK能否复制了

image-20230808140349298

image-20230808140404428

同步的很丝滑~

总结，在现有的mysql服务器基础上，实现主从复制

image-20230808142749357image-20230808142844062

生成中主从复制的错误案例

1、案例1

有人本该去主上创建库，结果跑到从节点上创建了；发现后又跑到主节点上创建了一遍。

错误如下

image-20230808143757752

然后去主上创建同名的库

image-20230808143949081

但是我这个没报错啊，难道是高版本优化？

然后我在主节点上删掉这个db003试试

image-20230808144319335

从节点此时就自动同步了，貌似高版本确实优化了

image-20230808144408283

老版本是由这个问题的，如下图👇

image-20230808150905874

这个问题的严重性在于：一旦发生这个错误，后续的主从复制就停滞了，继续在主节点上创建数据库，从节点就不会同步了。

这种冲突不仅仅是数据，这里只是举例，冲突可能存在于表，表里的记录都是可能的。

这里处理的方法不是在从上drop掉冲突的库，及时删掉，也不会继续同步的。需要stop salve和start slave，重启一下。但是生成中不能人工去处理的吖~而其是报错明确的，万一报错里的内容没有明确指出来呢，万一不止一条呢。

image-20230808152712362

image-20230808152817308

image-20230808152855538

按视频里说法就是忽略这个报错的意思咯，我先不急记录他的处理方法，我先看看高版本里的这种错是否由优化自动处理掉了。

image-20230808153723983

image-20230808153951356

image-20230808154103771

结果该问题确实有的，没有自动优化一说，继续处理吧。

image-20230808154129098

此时主节点那边开始写入大量数据，从节点就卡在那边不同步了

image-20230808161940806

此时从节点并不会同步

image-20230808162000625

skip忽略错误-sql_slave_skip_counter

其实不仅仅是忽略错误，只是一般用在忽略错误上，sql_slave_skip_counter是忽略几个同步事件，错误也好，正确也罢，都算！如果忽略2个，结果第一个是错误，第二个是正确的，一样也会被忽略。

image-20230808162737451

此时就可以同步复制了，之前主节点跑的存储过程其实就是创建和insert的testlog也同步过来了👇

image-20230808163011438

image-20230808163101723

当然忽略的1个报错，只是临时解决让数据继续同步下去，但是如果存在关联性，就不太好了，还是要回头过来去解决。

如果问题实在太多，还不如从的删掉，重新同步呢。

skip指定的error

再一个，尝试通过忽略错误编号的方式而不是忽略几个，这里要明确这个错误编号我测试下来不是说代表某一个错误，至少我insert 两次，忽略一次，1062的错误编号没变。

image-20230808164918937

image-20230808165213545

image-20230808165222861

image-20230808165924637

image-20230808170244621

不行唉，read-only也碍事了，改一下

image-20230808170344444

还是不对啊

image-20230808170434601

算了该配置文件去

image-20230808171126970

image-20230808171132576

image-20230808171111160

就好了。。。

image-20230808171150953

所以那几个insert都是1062类型的错？我理解成类型不知道对不对啊。

对的吧，官方有的https://mariadb.com/kb/en/mariadb-error-codes/

image-20230808172210391

如果主服务器宕机了

1、创建出1主2从的架构先

在主节点上执行
mysqldump -A --single-transaction --master-data=1 > /data/all2.sql
scp /data/all2.sql 192.168.126.131:/data

在从节点上执行

yum -y install mariadb-server

vim /etc/my.cnf
server-id=131
read-only
wr

systemctl restart mariadb

vim /data/all2.sql
----补齐-----
CHANGE MASTER TO
 MASTER_HOST='192.168.126.129',
 MASTER_USER='repluser',
 MASTER_PASSWORD='centos',
 MASTER_PORT=3306,
     #MASTER_LOG_FILE='mariadb-bin.000032',  这两行是自动就有的
     #MASTER_LOG_POS=548,         默认就有
 MASTER_CONNECT_RETRY=10;           # 注意最后一个才是分号

 wr

 mysql < /data/all2.sql

 mysql

 start slave;

 show slave status\G;                看见2个YES就OK啦。

上面执行的过程中报错了

image-20230808174727881

image-20230808204209734

image-20230808204235942

image-20230808204307572

①是版本不一致导致的

②是

https://stackoverflow.com/questions/1814532/mysql-error-1071-specified-key-was-too-long-max-key-length-is-767-bytes

③所以看懂了没？真实的意思就是，你的所有的字段，就是列的字符总和长度超了，而且还涉及一个字符占多个Bytes的情况。

这里不换版本，处理很麻烦，搞不懂的，除非你vim进去修改各个字段的长度，保证加起来不超过2000，但是没这么玩的；然后innodb_large_prefix这个10.5.x版本也不让改的-配置文件里修改了启动不了服务了。

④处理方法就是换一样的版本，

image-20230809110322391

好啦，瞎鸡巴搞，主从还不搞一样的版本！找抽！

image-20230809110921019

image-20230809111000374

模拟主从切换

image-20230809111314257

此时存储过程大量insert正在进行中，然后关闭虚拟机。

image-20230809111558528

image-20230809111618320

此时两个从节点，都瞎了。

此时需要提升一个从节点未主节点，提升谁的依据就是 谁的同步的二进制日志的位置新就提升谁，

image-20230809112103582

image-20230809112126543

一样的，谁都行。不一样，找编号文件大，文件编号一样，再找Pos位置编号大的。

这里两个从节点同步状态一样，就随便选择一个，这里选择192.168.126.130吧

提升为主的从节点的操作：
-------------------------------------
mysql > stop slave;
mysql > reset slave;   这个只是删掉master.info文件,删掉了relay-log.info，xx-rely-bin.000xxx也没了？老版本是好像清空但是这个rely-binlog还在的。
vim /etc/my.cnf
  log-bin  # 最好独立路径，这里偷个懒。做主了，从就要开启binlog了
  #read-only  # 要去掉。做住了，从就要支持写了。


账号之前就复制过来了，所以授权复制的账号不需要再创建了，可以确认下
mysql > select user,host,password from mysql.user;
mysql > show master logs;    # 看下提升为主得从，binlog从哪里开始的，待会还有一个从节点就从这里开始复制。

image-20230809133452875

image-20230809133514395

reset slave;清的不干净，需要加个all

image-20230809134140036

image-20230809134156592

不过新版，加不加all，/var/lib/mysql/的东西都是一样的效果了。

修改配置文件，这回儿提升为主了，需要修改一下

image-20230809135253777

提供从节点复制的账号本来就是复制过来的，有的

image-20230809135111123

image-20230809135759713

然后还有一个从节点也要修改master信息

msysql > stop slave;

mysql > reset slave all;


mysql > CHANGE MASTER TO
 MASTER_HOST='192.168.126.130',
 MASTER_USER='repluser',
 MASTER_PASSWORD='centos',
 MASTER_PORT=3306,
 MASTER_CONNECT_RETRY=10,
MASTER_LOG_FILE='bind-2-bin.000001', MASTER_LOG_POS=329;


mysql > start slave;
mysql > show slave status\G;

image-20230809135618908

image-20230809141135740

测试下同步效果

主节点上drop库，从上看

image-20230809141424545

image-20230809141433371

以上就是主从切换的手动过程，真实生产中，肯定不会这么手动搞吧，太慢了。

如何实现自动切换捏~(￣▽￣)~*有的，有个软件，呵呵，我还以为自己写脚本呢，对吧，自己写就是精度可能是s秒级的了不起了，后面学到这个软件再说。

减少主节点的压力

主从，主节点的工作就是复制写和同步，如果从过多，就会导致复制的IO过大，此时就会考虑：一主---中间节点----多个从节点，这样的架构👇

image-20230809161831661

从节点照旧，只是修改master指向中间节点就行；

中间节点的配置比较特别而已

那么问题来了

image-20230809173932272

中间的级联节点，是没有dump线程的，slave如何去取数据呢。

要知道简单的主-从，是靠dump thread讲binlog dump出来传出去得，从那边就是靠io thread接收数据，存到realy.log里，然后rely.log文件里得东西，又靠sql thread读取后写入数据库里得。

1、所以级联节点，必须启用binlog

2、而且这个binlog里记录得内容，必须是从master传递过来的内容，可不能是自身的binlog哦哦，哈哈，而默认恰恰是自身的binlog。

3、binlog默认是记录本地写入进去的，而不会记录 sql thread 从relay.log读取写入db的内容。而且中继上要只中继relay.log里的binlog才对。

4、还得dump thread来送出去。

总之 ，dump线程起来，然后dump只会从本地binlog取数据，不会从relay-log取，所以这里要做进一步处理。

image-20230809175640735

要让relay.log的数据写到数据库，然后让数据库里的数据再写道binlog，这样再利用dump进程才可以把从master来的binlog送出去。

image-20230809182600796

讲了辣么多，结果就是一条选项的事咩？

其实我还知道，这个TMD的处理逻辑还得优化成BLACKHONE的方式。

master上
--------
yum -y install mariadb-server


vim /etc/my.cnf
  server-id=1
  log-bin
wr

systemctl restart mariadb

mysql > grant replication slave on *.* to repluser@'192.168.126.%' identified by 'centos';

mysqldump -A -single-transaction --master-data=1 > /data/all.sql
scp /data/all.sql root@192.168.126.130:/data/

中间proxy上
--------
scp -r root@192.168.126.129:/etc/yum.repo/ /etc/
yum -y install mariadb-server

vim /etc/my.cnf
 server-id=130
 log-bin
 read-only
 log_slave_updates
wr

systemctl restart mariadb-server

vim /data/all.sql
 CHANGE MASTER TO
 MASTER_HOST='192.168.126.129',
 MASTER_USER='repluser',
 MASTER_PASSWORD='centos',
 MASTER_PORT=3306,
 MASTER_CONNECT_RETRY=10,
wr

msyql < /data/all.sql

mysql > show slave status\G;
mysql > start slave;

# 不用再proxy上创建复制账号，本意是创建账号给 从节点们用，其实没必要，proxy拿这个账号同步master，本身也会同步到这个账号到本地，然后从节点就用同样的账号来同步proxy。


mysqldump -A -single-transaction --master-data=1 > /data/all_proxy.sql
scp /data/all.sql root@192.168.126.131:/data/
scp /data/all.sql root@192.168.126.132:/data/

slave节点上
---------
scp -r root@192.168.126.129:/etc/yum.repo /etc/
yum -y install mariadb-server
vim /etc/my.cnf
    server-id=131
    read-only
wr

systemctl restart mariadb-server

vim /data/all_proxy.sql
 CHANGE MASTER TO
 MASTER_HOST='192.168.126.130',
 MASTER_USER='repluser',
 MASTER_PASSWORD='centos',
 MASTER_PORT=3306,
 MASTER_CONNECT_RETRY=10,
wr


msyql < /data/all.sql

mysql > show slave status\G;
mysql > start slave;

以上配置OK，测试过了，过程截图略了，都是从yum -y remove mariadb开始的

最后验证：

image-20230810115102645

image-20230810115125632

image-20230810115137085

image-20230810115145789

OK，

image-20230810115205327

这种的搞定

Copyright 🌹 © oneyearice@126.com 2022 all right reserved，powered by Gitbook文档更新时间： 2024-07-28 14:47:50

results matching ""

    No results matching ""