mysql5.5 中mysqldump 与metadata lock及其参数--dump_slave问题注意

周末闲的无事，在家折腾mysql的各种备份工具，测试出以前没有注意的一些东东，现记录如下：

mysql 版本 5.5.34

1，mysqldump 与metadata lock

[root@host93 bin]# ./mysqldump -uroot -pxxx -h 127.0.0.1 -P 3308 --single-transaction --databases yiqifa_xxx test > backup.test.dmp

开启另一个会话在test库下执行：

(user:root time: 21:08)[db: test]alter table test2 modify name varchar(50);

Query OK, 0 rows affected (0.01 sec)

Records: 0 Duplicates: 0 Warnings: 0

test在后面的时候在dump没有完成时依然可以对test 库执行ddl即，没有dump到的库表不会加metadata lock

将数据库顺序调换一下顺序test放前面

[root@host93 bin]# ./mysqldump -uroot -pxxx -h 127.0.0.1 -P 3308 --single-transaction --databases test yiqifa_xxx > backup.test.dmp

开启另一个会话在test库执行 alter table test2 modify name varchar(500) 发现

| 106517 | root | localhost | test | Query | 8 | Waiting for table metadata lock | alter table test2 modify name varchar(500)

只要所有的库没有都dump完成，那么任何库表上的metadata lock 一直不释放 （如果想备份的时候依然可以对其他尚未备份的库进行ddl，那么你可以将小库放在最后面）

这里还需要注意一点：虽然备份过程中对已经存在的表无法进行ddl操作，但在备份时间点之后的新建表和删除新建的表等操作是没有metadata lock的

ERROR 1317 (70100): Query execution was interrupted

(user:root time: 21:02)[db: test]create table a (id int ); drop table a;

Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected (0.00 sec)

(user:root time: 21:02)[db: test]use yiqifa_xxx;

Database changed

(user:root time: 21:03)[db: yiqifa_xxx]create table a (id int ); drop table a;

Query OK, 0 rows affected (0.01 sec)

奇思怪想：如何才能人为在dump的时候消除metadata lock （当然这个一般没啥意义）

其实可以直接把 --single-transaction 去掉另外加上--skip-lock-tables 这样就可以。

2， mysqldump 参数 --dump_slave对mysql的影响

先看一下关于该参数的解释：

--dump-slave[=#] This causes the binary log position and filename of the

master to be appended to the dumped data output. Setting

the value to 1, will printit as a CHANGE MASTER command

in the dumped data output; if equal to 2, that command

will be prefixed with a comment symbol. This option will

turn --lock-all-tables on, unless --single-transaction is

specified too (in which case a global read lock is only

taken a short time at the beginning of the dump - don't

forget to read about --single-transaction below). In all

cases any action on logs will happen at the exact moment

of the dump.Option automatically turns --lock-tables off.

上面这段话大概的意思是：该参数会将当前备份复制到主库的binlog文件名和相应位置记录到备份文件设置为1会添加change master 语句，2 则在1的基础上在change master 的最前面添加注释 即”--“ ，如果该参数和 --single-transaction 结合使用那么在dump开始的很短时间里会加一个全局读锁，否则就会开启 --lock-all-tables ，在任何情况下该参数都会使得--lock-tables失效。

现在测试如下

[root@host105 mysql_bak]# time mysqldump -uroot -pxxxx yiqifa_xxxx --dump_slave=2 --single-transaction >yiqifa_xxxx.dmp

在dump过程中开启另一个会话show slave status \G 查看：

************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.5.112

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000294

Read_Master_Log_Pos: 721937777

Relay_Log_File: mysql-relay-bin.000876

Relay_Log_Pos: 49712363

Relay_Master_Log_File: mysql-bin.000294

Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table: %.%

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 721924316

Relay_Log_Space: 721938225

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: 127112

1 row in set (0.00 sec)

备份完成后打开备份文件，查看前面50行左右可见到

--

-- Position to start replication or point-in-time recovery from (the master of this slave)

--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000294', MASTER_LOG_POS=721924316;

上述结果显示：change master 里面的值 master_log_file 表示当前备库复制到主库的binlog文件名，master_log_pos 表示当前备库执行到主库binlog

的位置（注意不是读取到master的位置），同时你还会看到sql_thread 处于NO的状态，可见加入--dump_slave后mysqldump会执行stop salve sql_thread

操作，直到完成备份后才会重新开启sql thread 因此，如果你有对复制进程进行监控的话这个时候可能会有大量的告警。

特别注意：

如果在dump过程中因为一些其他因素如手动ctrl+c 或kill掉进程等，那么你必须手动执行start slave 否则sql_thread线程会一直处于NO状态。

另外,同时添加--master-data=2 参数的话生效的也是--dump_slave=2 即--dump_slave 的优先级高于--master-data （可以自行测试）

为了让change master 更加详细，你还可以添加--include-master-host-port参数dump后结果如下：

--

-- Position to start replication or point-in-time recovery from (the master of this slave)

--

-- CHANGE MASTER TO MASTER_HOST='192.168.5.112', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000294', MASTER_LOG_POS=728464927;

说到这里不得不提一些另外一个mysql多线程备份工具mydumper （关于该工具的介绍会在之后分享），它在备份过程也会记录复制的信息但不会导致sql_thread的停止。

本文完.. ...

新浪微博：freedom3959

qq ： 554370286