利用binlogserver恢复单表实验【转】

使用场景

每次开启binlogserver 指定了mysql-bin.0000XX 后都会从该点从头进行传输一次

创建binlogserver

[root@mysql-zst3 binlogserver]# nohup mysqlbinlog --raw --read-from-remote-server --host=172.0.0.51 --port=3308 --user=repl3307 --password=repl --stop-never mysql-bin.000043 &

[2] 8009

 

此时sbtest_bk数据数，此时binlog位置，且binlogserver正常

 

进行truncate table

t1 表现在数据

进行truncate

 

在truncate table 修改主键 为跳跃性的id，紧接着应该进行flush log

"root@localhost:mysql3308.sock [systest]>truncate table t1;

Query OK, 0 rows affected (0.17 sec)

 

"root@localhost:mysql3308.sock [systest]>insert into t1(id) values(40000)

 

模拟继续插入数据

查看此时log-file

可以确认 有tuncate 的log-file 在46上

 

 

这次实验目的是学会使用全备+binlogserver 进行恢复数据

这里的全备使用的是xtrabackup，

恢复综述：

1使用xtrabackup 创建出一个实例（3011）

2在创建一个新实例（3012）存放binlogserver的日志作为3011的伪master

3.创建主从同步日志恢复到truncate前

 

可能遇到的问题：

1.binlogserver的日志中记录的是原库3308 的gtid，可能会有问题

解决办法是不是用auto_master_positon=1

但是在使用xtrabackup恢复的实例3011的gtid是否和3308一致？

 

创建3311 伪master

正确操作

在3311上进行操作：

1、reset master

2、关闭3311实例

3、删除3311实例logdir下所有文件

4、将binlog server下的binary log拷贝到logdir，生成mysql-bin.index文件，修改权限

5、启动3311，show master status

结果是

 

 

=========================================================================

这里记录一个错误

将binlogserver日志拷贝到3311实例的logs目录下，并修改权限

这里做的顺序是：先启动实例修改root密码，增加复制用户，关闭实例，修改mysql-bin.index .启动实例

修改mysql-bin.index方法

[root@mysql-zst3 logs]# ls /data/mysql/mysql3311/logs/mysql-bin.0000* > mysql-bin.index 

 

 此时3311实例的binlog 会发生变化

mysql-bin.00001是最开始生成的，mysql-bin.000048 是由于在第一次启动实例前把日志放到了log目下生成的因此增加复制用户的操作在000048上；mysql-bibn.000049 是修改mysql-bin.index后重启mysql生成的

其他的日志则是mysqlbinlogserver 的日志

注意这里的gtid的serverid（7709xxxx412:1-4)是新生成的和3308的是不一样的，因此在搭建主从的时候可能会影响，且并没有执行传进来的binlog。

这里有个错误：

关于execute_gtid_set这个值。这里我的操作是：初始化库之后修改root密码，添加复制账户。关库，复制binlogserver日志，修改index文件，启动库，因此这里的execute_gtid_set 没有读到日志里的3308的gtid。但是在次执行该操作时就会读出来，即使没有做reset master,但是建议适用reset master后进行重启库

则会读出3308的gtid

关于execute_gtid_set 和binlog_gtid_simple_recovery参数有关，大概作用是重启mysql时读取mysql-bin.index 中文件从头到尾的日志里的所有gtid集合

详细内容可看文章http://www.cnblogs.com/Uest/p/8319134.html

 

错误记录结束

=============================================================================

搭建3312 作为3311的slave进行恢复

这个3312实例：使用的是的3308 使用xtrabackup的全备进行恢复的。

这里做了一个特殊的操作，如果有需要的可以参考，不需要可不许操作:这里只恢复systest库因此我吧其他库都删除了

除了系统库只剩了systest库

此时观察xtrbackup_binlog_pos_innodb 内的日志位置和xtrabackup_info 是不同的

不过可以进行解析mysql-bin.000046 这里有没有操作（xtrabackup_info记录的是日志里的，因此会比xtabackup_binlog_pos_innodb(记录redo里的）可能会高一些。如果有操作需要手动进行恢复了如手动执行sql，或者日志导入，一般是ddl语句，ddl语句不记录到redo中。或者压根就没操作~~）

启动3312实例

 systest库存在

此时3312的状态

 

搭建主从

1.使用MASTER_AUTO_POSITION=1

"root@localhost:mysql3312.sock [systest]>change master to

-> master_host='172.0.0.52',

-> master_port=3311,

-> master_user='repl',

-> master_password='repl',

-> master_auto_position=1;

Query OK, 0 rows affected, 2 warnings (0.11 sec)

 

指定停止点

"root@localhost:mysql3312.sock [systest]>start slave sql_thread until sql_before_gtids='e2b6a2cf-2e3c-11e8-a9cd-000c29817dea:133'; 注意该value为一个值不是范围

Query OK, 0 rows affected (0.02 sec)

 

开启io_thread

start slave io_thread

2使用master_auto_positon=0搭建主从

确认logfile，logpos起始点

检查xtrabackup_binlog_info上的位置mysql-bin.000046 234 83bc1292-48fe-11e8-b4e2-000c29f1c412:1, 是没有操作的不需要从这开始）

因此确定logfie=mysql-bin.000045

logpos=

 

change master to

master_host='172.0.0.52',

master_port=3311,

master_user='repl',

master_password='repl',

master_log_file='mysql-bin.000045',

master_log_pos=5729109,

master_auto_position=0

 

注意点：

在开启主从也需要停止在truncate table 的事物位置前。

找到truncate table 的位置

mysql-bin.000046上解析，

SET @@SESSION.GTID_NEXT= 'e2b6a2cf-2e3c-11e8-a9cd-000c29817dea:133'/*!*/;为truncate 操作

start slave sql_thread until master_log_file='mysql-bin.000046',master_log_pos=1910151;

在开启io_thread，检查t1表数据，已恢复

此时gtid会发生变化

 

 转自

archer_66的有道云笔记
https://note.youdao.com/share/?id=d5ba0c54eaeea9cba421f9297a786a29&type=note#/

知数堂 - 最靠谱、最有品质的培训品牌

http://zhishutang.com/