MYSQLdrop多个database

文章目录

• 第1章 基于异步主从复制(Gtid+replication)架构
• 1.1 第一种情况
• 1.2 第二种情况

第1章 基于异步主从复制(Gtid+replication)架构

1.1 第一种情况

在slave上把默认的mysql库给drop掉了,此时我没做stop slave; 也没有重启角色为slave的mysql实例

当前状态
主从复制正常(正常同步master端的数据且能够应用,就是slave的IO和SQL线程正常),它的状态如下

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
.......................................省略
.......................................省略
Retrieved_Gtid_Set: 6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-11    # slave从master端检索到的GTID集
 Executed_Gtid_Set: 6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-11    # slave执行了master端的哪些GTID集

所做操作(在slave上做的操作)
在slave上不小心把自身默认的 mysql 库给 drop 掉了;但我没有做 stop slave;操作,也没重启角色为slave的mysql实例;

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
.......................................省略
.......................................省略
Retrieved_Gtid_Set: 6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-11   # slave从master端检索到的GTID集
 Executed_Gtid_Set: 1c791984-f25a-11ea-97d0-000c298f04d2:1,     # 自身执行的事务集只有1条,前面drop
                    6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-11   # slave执行了master端的哪些GTID集

带来的后果
01：master端能够正常提供读写,是在产生事务的,假如事务ID是：xxxxxxxxxx:12，slave的状态就会报错,冲突事务就是12

Slave_IO_Running: Yes
Slave_SQL_Running: No
Retrieved_Gtid_Set: 6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-12  # slave从master检索引到的GTID集,可看到是12
 Executed_Gtid_Set: 1c791984-f25a-11ea-97d0-000c298f04d2:1,    # slave自身执行的GTID集,前面drop语句;
	                6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-11  # slave执行了从master检索过来的1-11

02:master端可能还在产生数据(你要考虑到哈),数据依然会同步到slave,slave的IO线程还是存放到中继日志中;

解决方法(主要是在slave上的操作)

-- 首先声明
	01：我每天在slave上有对mysql库做单库逻辑全备,备份工具是mysqlpump工具,在备份时是加了--flush-privileges参数的哈
	
	
-- 第一阶段:(查看gtid的相关变量)
   01：使用 select @@global.gtid_executed; 可看到事务是：6f108d1f-f133-11ea-93a4-000c29e5fcf9:11
   02：因为 slave 只执行到了从master检查过来的GTID标识为11的事务;标识为12的GTID就冲突了;
       

-- 第二阶段:（找到备份的数据--->修改--->导入）
   01：将备份的数据文件找出来,进行编辑后并保存,编辑的内容如下所示：
	   A：文件开头加 set session sql_log_bin=0;
	   B：文件末尾加 set session sql_log_bin=1;
   02：将"02"步骤的文件导入到slave中;
   03：此时你查看复制帐号是有的,权限是有的;
   04：但 mysql.slave_master_info mysql.gtid_executed  mysql.slave_relay_log_info 这三张表都是空的;


-- 第三阶段：
   01：停止slave；使用命令：stop slave;
   02：启动slave，使用命令：start slave;            
       A：此时主从状态正常,能够正常同步数据；
       B: mysql.slave_master_info表和 mysql.slave_relay_log_info表有数据
       C：但mysql.gtid_executed表没有数据
   03：查看slave状态，使用命令：show slave status;  # 以下的状态是最关键的哈
	   Slave_IO_Running: Yes
	   Slave_SQL_Running: Yes
	   Retrieved_Gtid_Set: 6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-12 # slave从master检索引到的GTID集,可看到是12
	   Executed_Gtid_Set: 1c791984-f25a-11ea-97d0-000c298f04d2:1,    # slave自身执行的GTID集,前面drop语句;
	                      6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-12  # slave执行了从master检索过来的 1-12
   04：但还有一个问题：binlog中记录了drop database mysql;命令,万一这台slave是有机会提升为主的呢
   05：清空slave的binlog日志
       A：注意:不要stop slave哈;若stop slave;再清理,后面的处理方法就不同了哈;
       B：set session sql_log_bin=0;  # 当前会话不记录binlog
       C：reset master;               # 清空binlog文件,重新生成binlog文件,同时清空gtid_executed变量的值
       D：setsession sql_log_bin=1;   # 当前会话记录binlog
   06:再查看slave的状态,这个状态是
	   Slave_IO_Running: Yes
	   Slave_SQL_Running: Yes
	   Retrieved_Gtid_Set: 6f108d1f-f133-11ea-93a4-000c29e5fcf9:1-12 # slave从master检索引到的GTID集,可看到是12
	   Executed_Gtid_Set:                                            # 没有执行的,当然我master端没产生事务
   06：重启角色为slave的mysql实例;
       A：停止时：会将Retrieved_Gtid_Set:的值记录到mysql.gtid_executed表中
       B：启动时：读取mysql.gtid_executed表中的值,

1.2 第二种情况

在slave上把默认的mysql库给drop掉了,此时我重启角色为slave的mysql实例

#### 当前状态
主从复制正常(正常同步master端的数据且能够应用,就是slave的IO和SQL线程正常)

#### 所做操作
在slave上不小心把mysql库给drop掉了，但我有重启角色为slave的mysql实例.

#### 带来的后果
角色为slave的mysql实例重启不了；

#### 解决方法
-- 第一阶段(将重启不了的slave进行重新初始化)
	01:将数据目录(datadir)下的文件移走;
    02:用mysqld进行重新实例化;
    03:启动实例,修改超级用户的密码;
    04:清空binlog日志(reset master; 刚初始化的实例,没有数据,放心用这个命令)
     	
-- 第二阶段(在master端操作)
	01:以下是用mysqldump命令备份的命令,我有记录gtid、有加--flush-privileges参数
	   mysqldump --no-defaults -uroot -pchenliang -S /data/mysql/3306/run/mysql.sock \
	   --set-gtid-purged=on -F --master-data=2 --single-transaction \
	   -A --flush-privileges --skip-extended-insert -R -E --triggers |gzip >/tmp/master-all-object.sql.gz
    02:尽量在低峰期进行备份
    03:将数据传输至slave服务器上
     
-- 第三阶段(在slave上进行操作)
	01:在将传输过来的数据导入到mysql实例
    02:进行change master
    03:start slave;
    04:show slave status;