週末閒的無事，在家折騰mysql的各種備份工具，測試出以前沒有注意的一些東東，現記錄如下：

mysql 版本 5.5.34

1，mysqldump 與metadata lock

[[email protected] 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放前面

[[email protected] 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失效。

現在測試如下

[[email protected] 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