使用 mysqldump 備份數據庫時避免鎖表
1.導出表時默認會枷鎖
備份數據庫時 用 命令 mysqldump -u user -p xxx>xxx.sql發現沒有完全備份數據庫記錄，加上 --skip-opt選項後好了
對一個正在運行的數據庫進行備份請慎重！！ 如果一定要 在服務運行期間備份，請添加 --skip-opt選項，
類似執行： mysqldump --skip-opt -u root --password=123456 dbname >mysql.SQL
2.開啓一致性事務
--opt 會lock 本次需要備份的所有表，因爲本次備份的是 dbname數據庫，所以會鎖住dbname的所有表。
--master-data=2，--master-data=1 默認的話會--lock-all-tables，會鎖住整個mysql數據庫中的所有表。
但是如果加上--single-transaction會加上事務，不會鎖表
在用mysqldump備份使用那些參數選項是最完美的組合呢？
--skip-opt
--create-options ----添加create相關的選項
--single-transaction ----一致性備份
-q ----採用快速的dump方式(提高導出性能)
-e ----採用多重insert語句形式(提高還原性能)，當一個表的數據量很大情況下不知道會不會導致死鎖？
--no-autocommit ----採用批量提交方式(提高還原性能)
-R ----導出存儲過程，函數，和觸發器
--master-data=2 ----如果有寫log-bin且版本爲5.0以上的版本，則再加上 --master-data=2
--events ----如果是5.1以上的版本使用，包含事件
*************
在mysqldump過程中，之前其實一直不是很理解爲什麼加了--single-transaction就能保證innodb的數據是完全一致的，而myisam引擎無法保證，必須加--lock-all-tables，前段時間抽空詳細地查看了整個mysqldump過程。
理解master-data和--dump-slave
--master-data=2表示在dump過程中記錄主庫的binlog和pos點，並在dump文件中註釋掉這一行；
--master-data=1表示在dump過程中記錄主庫的binlog和pos點，並在dump文件中不註釋掉這一行，即恢復時會執行；
--dump-slave=2表示在dump過程中，在從庫dump，mysqldump進程也要在從庫執行，記錄當時主庫的binlog和pos點，並在dump文件中註釋掉這一行；
--dump-slave=1表示在dump過程中，在從庫dump，mysqldump進程也要在從庫執行，記錄當時主庫的binlog和pos點，並在dump文件中不註釋掉這一行；
注意:在從庫上執行備份時，即--dump-slave=2，這時整個dump過程都是stop io_thread的狀態
深入理解--single-transaction：
打開general_log，準備一個數據量較小的db，開啓備份，添加--single-transaction和--master-data=2參數，查看general_log，信息如下，每一步添加了我的理解
整個dump過程是同一個連接id 32，這樣能保證在設置session級別的變量的時候不影響到其他連接
thread_id: 32
argument: ucloudbackup@localhost on
*************************** 14. row ***************************
thread_id: 32
argument: /*!40100 SET @@SQL_MODE='' */
*************************** 15. row ***************************
thread_id: 32
argument: /*!40103 SET TIME_ZONE='+00:00' */
*************************** 16. row ***************************
thread_id: 32
argument: FLUSH /*!40101 LOCAL */ TABLES
*************************** 17. row ***************************
thread_id: 32
argument: FLUSH TABLES WITH READ LOCK
批註：因爲開啓了--master-data=2，這時就需要flush tables with read lock鎖住全庫，記錄當時的master_log_file和master_log_pos點
*************************** 18. row ***************************
thread_id: 32
argument: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
批註：--single-transaction參數的作用，設置事務的隔離級別爲可重複讀，即REPEATABLE READ，這樣能保證在一個事務中所有相同的查詢讀取到同樣的數據，也就大概保證了在dump期間，如果其他innodb引擎的線程修改了表的數據並提交，對該dump線程的數據並無影響，然而這個還不夠，還需要看下一條
*************************** 19. row ***************************
thread_id: 32
argument: START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
這時開啓一個事務，並且設置WITH CONSISTENT SNAPSHOT爲快照級別（如果mysql版本高於某一個版本值，我還不大清楚40100代表什麼版本）。想象一下，如果只是可重複讀，那麼在事務開始時還沒dump數據時，這時其他線程修改並提交了數據，那麼這時第一次查詢得到的結果是其他線程提交後的結果，而WITH CONSISTENT SNAPSHOT能夠保證在事務開啓的時候，第一次查詢的結果就是事務開始時的數據A，即使這時其他線程將其數據修改爲B，查的結果依然是A，具體的測試看我下面的測試結果
*************************** 20. row ***************************
thread_id: 32
argument: SHOW MASTER STATUS
這時候執行這個命令來記錄當時的master_log_file和master_log_pos點，注意爲什麼這個時候記錄，而不是再18 row和19 row之間就記錄，個人認爲應該都是可以的，這裏是測試結果，start transaction並不會產生binlog的移動，而18 row和19 row的動作也在同一個thread id中
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 1690 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
*************************** 21. row ***************************
thread_id: 32
argument: UNLOCK TABLES
等記錄完成後，就立即釋放了，因爲現在已經在一個事務中了，其他線程再修改數據已經無所謂，在本線程中已經是可重複讀，這也是這一步必須在19 rows之後的原因，如果20 rows和21 rows都在19 rows之前的話就不行了，因爲這時事務還沒開啓，一旦釋放，其他線程立即就可以更改數據，從而無法保證得到事務開啓時最準確的pos點。*************************** 22. row ***************************
thread_id: 32
argument: SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='mysql' AND TABLE_NAME IN ('user'))) GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME
*************************** 23. row ***************************
thread_id: 32
argument: SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='mysql' AND TABLE_NAME IN ('user')) ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
*************************** 24. row ***************************
thread_id: 32
argument: mysql
*************************** 25. row ***************************
thread_id: 32
argument: SHOW TABLES LIKE 'user'
*************************** 26. row ***************************
thread_id: 32
argument: show table status like 'user'
dump表以前都需要show一下各自信息，確保表，視圖等不損壞，可用，每一步錯了mysqldump都會報錯並中斷，給出對應的錯誤碼，常見的myqldump錯誤請參考我的另外一篇blog http://blog.csdn.net/cug_jiang126com/article/details/49359699
*************************** 27. row ***************************
thread_id: 32
argument: SET OPTION SQL_QUOTE_SHOW_CREATE=1
*************************** 28. row ***************************
thread_id: 32
argument: SET SESSION character_set_results = 'binary'
*************************** 29. row ***************************
thread_id: 32
argument: show create table `user`
*************************** 30. row ***************************
thread_id: 32
argument: SET SESSION character_set_results = 'utf8'
*************************** 31. row ***************************
thread_id: 32
argument: show fields from `user`
*************************** 32. row ***************************
thread_id: 32
argument: SELECT /*!40001 SQL_NO_CACHE */ * FROM `user`
這就是我們show processlist時看到的信息，而數據是怎麼通過一條select語句就dump到本地文件裏的呢，並且還轉成成相應的create和insert語句，這就是mysqldump這個客戶端工具的工作了，這裏不做討論
*************************** 33. row ***************************
最後並沒有看到commit，因爲在整個事務中，其實並沒有修改任何數據，只是爲了保證可重複讀得到備份時間點一致性的快照，dump完成後提交不提交應該無所謂了。
myisam引擎爲什麼無法保證在--single-transaction下得到一致性的備份？
因爲它壓根就不支持事務，自然就無法實現上述的過程，雖然添加了--single-transaction參數的myisam表處理過程和上面的完全一致，但是因爲不支持事務，在整個dump過程中無法保證可重複讀，無法得到一致性的備份。而innodb在備份過程中，雖然其他線程也在寫數據，但是dump出來的數據能保證是備份開始時那個binlog pos的數據。
myisam引擎要保證得到一致性的數據的話，他是如何實現的呢？
它是通過添加--lock-all-tables，這樣在flush tables with read lock後，直到整個dump過程結束，斷開線程後纔會unlock tables釋放鎖(沒必要主動發unlock tables指令)，整個dump過程其他線程不可寫，從而保證數據的一致性
如果我一定要在mysiam引擎中也添加--single-transaction參數，再用這個備份去創建從庫或恢復到指定時間點，會有什麼樣的影響？
我個人的理解是如果整個dump過程中只有簡單的insert操作，是沒有關係的，期間肯定會有很多的主鍵重複錯誤，直接跳過或忽略就好了。如果是update操作，那就要出問題了，分幾種情況考慮
1） 如果是基於時間點的恢復，假設整個dump過程有update a set id=5 where id=4之類的操作，相當於重複執行兩次該操作，應該問題不大
2） 如果是創建從庫，遇到上面的sql從庫會報錯，找不到該記錄，這時跳過就好
3）不管是恢復還是創建從庫，如果dump過程中有update a set id=id+5 之類的操作，那就有問題，重複執行兩次，數據全變了。
深入理解--lock-all-tables
打開general_log，準備一個數據量較小的db，開啓備份，添加--lock-all-tables(其實也是默認設置)和--master-data=2參數，查看general_log，信息如下，理解--lock-all-tables怎麼保證數據一致性
mysql> select thread_id,argument from general_log where thread_id=185\G
*************************** 1. row ***************************
thread_id: 185
argument: [email protected] on
*************************** 2. row ***************************
thread_id: 185
argument: /*!40100 SET @@SQL_MODE='' */
*************************** 3. row ***************************
thread_id: 185
argument: /*!40103 SET TIME_ZONE='+00:00' */
*************************** 4. row ***************************
thread_id: 185
argument: FLUSH /*!40101 LOCAL */ TABLES
*************************** 5. row ***************************
thread_id: 185
argument: FLUSH TABLES WITH READ LOCK
這裏flush tables with read lock之後就不會主動unlock tables，保證整個dump過程整個db數據不可更改，也沒有事務的概念了
*************************** 6. row ***************************
thread_id: 185
argument: SHOW MASTER STATUS
同樣記錄主庫的位置
*************************** 7. row ***************************
thread_id: 185
argument: SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME
*************************** 8. row ***************************
thread_id: 185
argument: SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
*************************** 9. row ***************************
thread_id: 185
argument: SHOW DATABASES
*************************** 10. row ***************************
thread_id: 185
argument: jjj
*************************** 11. row ***************************
thread_id: 185
argument: SHOW CREATE DATABASE IF NOT EXISTS `jjj`
測試可重複讀和快照讀(WITH CONSISTENT SNAPSHOT )
準備工作3.1（測試可重讀）
session 1:
mysql> select * from xx;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
+------+
mysql> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Query OK, 0 rows affected (0.00 sec)
設置事務隔離級別爲可重複讀
mysql> START TRANSACTION ;
Query OK, 0 rows affected (0.00 sec)
我們先不開快照讀觀察現象
session 2:
mysql> insert into xx values (5);
Query OK, 1 row affected (0.00 sec)
session 1:
mysql> select * from xx;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+
5 rows in set (0.00 sec)
批註：這時因爲沒有設置快照讀，所以當session 2有數據更新時，可查到該數據，接
下來我們繼續在session 2 插入數據
session 2:
mysql> insert into xx values (6);
Query OK, 1 row affected (0.00 sec)
這時再觀察session 1的數據
session 1
mysql> select * from xx;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+
5 rows in set (0.00 sec)
查詢發現還是隻有5條，表示可重複實現了。
準備工作3.2（測試快照讀）
session 1
mysql> select * from xx;
+------+
| id |
+------+
| 1 |
+------+
1 row in set (0.00 sec)
mysql> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Query OK, 0 rows affected (0.00 sec)
mysql> START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */;
Query OK, 0 rows affected (0.00 sec)
這時我們在session 2插入數據
session 2：
mysql> insert into xx values (2);
Query OK, 1 row affected (0.00 sec)
這時我們再觀察session 1的結果
session 1：
mysql> select * from xx;
+------+
| id |
+------+
| 1 |
+------+
1 row in set (0.00 sec)
發現還是隻有一條數據，證明實現了快照讀
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from xx;
+------+
| id |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)
事務1 提交後方可看見第二條記錄
---------------------
作者：胡兒胡兒
來源：CSDN
原文：https://blog.csdn.net/cug_jiang126com/article/details/49824471
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！