mysql通过物理备份主库方式恢复从库

1     场景描述

有一套主从环境,从库和主库差异量比较大。其中一个库大小800G左右,127个表,平均每个表差异100万条数据。试过用pt-table-checksum,pt-table-sync进行同步,但是太慢了,平均同步一个表需要5个小时。因此,打算通过拷贝主库表空间文件,表结构定义文件,日志文件等到从库的方式,使得从库和主库保持一致。

2      变更步骤


2.1 停止从库

service mysqld stop

修改配置文件,添加skip-slave-start,避免从库启动时自动启动复制(因为默认数据库自动时会自动启动复制,会从上一次slave停止的位置自动继续复制,这里避免自动启动,是为了后面可以change master to自定义开始复制的位置)。

2.2 删除从库表空间文件和数据库文件

cd /database1/mysql

rm -rf DatabaseName1 DatabaseName2

rm -rf ibdata1

2.3 从主库拷贝数据文件和表空间文件

确保先停掉主库上的业务。

锁定主库,记录下当前binlog日志及position,方便从库后续从这个位置开始复制。

mysql> flush tables with read lock;

Query OK, 0 rows affected (0.00 sec)

 #为什么停掉业务了,还要加个读锁呢,为了以防万一,嘿嘿,有时存在定时任务,也会对数据库进行增删改。  

mysql> show master status;

+--------------------+----------+--------------+------------------+

| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+--------------------+----------+--------------+------------------+

|| master1-bin.001434 | 13144499      |                  |

+--------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

 

--拷贝数据库文件

cd /mysql_data1/mysql

scp -r DatabaseName1 DatabaseName2 从库IP:/database1/mysql/

 

--拷贝完数据文件后,开始拷贝日志文件

在从库上先备份下之前的日志文件

cd /database1/mysql

mv ib_logfile0 ib_logfile0_bak_07152225

mv ib_logfile1 ib_logfile1_bak_07152225

mv ib_logfile2 ib_logfile2_bak_07152225

 

在主库上拷贝:

scp /mysql_data1/mysql/ib_logfile*从库IP:/database1/mysql/

 

日志文件拷贝完成后,开始拷贝共享表空间文件

在从库上启动netcat(netcat适合大数据量的拷贝):

nc -l  30240> /database1/mysql/ibdata1

在主库上:

nc  从库IP 30240 < /mysql_data1/mysql/ibdata1

拷贝完成后,解锁

mysql> unlock tables;

Query OK, 0 rows affected (0.00 sec)

 

--修改owner

在从库上执行:

chown -R mysql:mysql DatabaseName1 DatabaseName2ibdata1

chown -R mysql:mysql ib_logfile*

2.4启动从库

service mysqld start

看是否还报错,观察几分钟,看进程是否还在。

2.5 开启复制

mysql> showslave status \G;
***************************1. row ***************************
               Slave_IO_State:
                  Master_Host: ……
                  Master_User: replica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File:master1-bin.001423
          Read_Master_Log_Pos: 40860837
               Relay_Log_File:web_appdb_10-relay-bin.000671
                Relay_Log_Pos: 40860985
        Relay_Master_Log_File:master1-bin.001423
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:np002.%,ccda.%,eip_fileservice.%
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 40860837
              Relay_Log_Space: 40863264
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert:No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 0
1 row in set (0.00sec)
 
ERROR:
No query specified

指向当时锁定的位置:

change master tomaster_host='主库

IP',master_log_file='master1-bin.001434',master_log_pos=13144499;

 start slave;

确保IO进程和SQL进程都为Yes.

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

 

观察Seconds_Behind_Master,确保其最后值为0.

3      检查测试

抽查主库和从库的几个表记录条数是否一致。

也可以用percona toolkit工具抽查几个表,看是否存在差异。

没问题后,让同事开启业务。

 

/*

本实验需要停掉业务,禁止在主库上写数据。因为倘若主库上有读写的话,恢复完从库,会导致无法启动从库,错误日志报错:

160709 5:47:10  InnoDB: Error: page 7 logsequence number 7229203959465

InnoDB: is in the future! Current system logsequence number 6245064532384.

InnoDB: Your database may be corrupt or youmay have copied the InnoDB

InnoDB: tablespace but not the InnoDB logfiles. See

InnoDB:http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

InnoDB: for more information.

我按网上说的,在从库配置文件里添加参数innodb_force_recovery=n,后来虽然从库能启动成功了,但是却无法读写数据,便没有采取该方案。

mysql>insert into np002.pending_0(_id) values('dan');

ERROR1030 (HY000): Got error -1 from storage engine

 

错误日志报错:

InnoDB: Anew raw disk partition was initialized or

InnoDB:innodb_force_recovery is on: we do not allow

InnoDB:database modifications by the user. Shut down

InnoDB:mysqld and edit my.cnf so that newraw is replaced

InnoDB:with raw, and innodb_force_... is removed.

 

也有的说可以move theInnoDB log sequence number (LSN) forward,参考:https://www.percona.com/blog/2013/09/11/how-to-move-the-innodb-log-sequence-number-lsn-forward/,但我没试验,以后有机会再试验吧。

 */

 

 

你可能感兴趣的:(1,MySql,学习,#,Mysql,主从复制,#,MySql,备份恢复,#,MySql,报错集锦)