葉問【轉自知數堂微信公衆號】

時間 2019-12-18

標籤葉問轉自知數堂微信公衆號简体版

原文原文鏈接

轉自mysql

《葉問》是知數堂新設計的互動欄目，不按期給你們提供技術知識小貼士，形式不限，或提問、或討論都可，並在當天發佈答案，讓你們輕輕鬆鬆利用碎片時間就能夠學到最實用的知識點。sql

知數堂 - 最靠譜、最有品質的培訓品牌 http://www.3wedu.net/數據庫

葉問專輯 https://mp.weixin.qq.com/mp/homepage?__biz=MzI1OTU2MDA4NQ%3D%3D&hid=15&sn=8a530aa309c1fe6e4d99b3a0d49a9695安全

2018年6月10日，週日服務器

MySQL主從複製什麼緣由會形成不一致，如何預防及解決？網絡

1、致使主從不一致的緣由主要有： 架構

人爲緣由致使從庫與主庫數據不一致（從庫寫入）併發
主從複製過程當中，主庫異常宕機app
設置了ignore/do/rewrite等replication等規則運維
binlog非row格式
異步複製自己不保證，半同步存在提交讀的問題，加強半同步起來比較完美。但對於異常重啓（Replication Crash Safe），從庫寫數據（GTID）的防範，還須要策略來保證。
從庫中斷好久，binlog應用不連續，監控並及時修復主從
從庫啓用了諸如存儲過程，從庫禁用存儲過程等
數據庫大小版本/分支版本致使數據不一致？，主從版本統一
備份的時候沒有指定參數例如mysqldump --master-data=2 等
主從sql_mode 不一致
一主二從環境，二從的server id一致
MySQL自增列主從不一致
主從信息保存在文件裏面，文件自己的刷新是非事務的，致使從庫重啓後開始執行點大於實際執行點
採用5.6的after_commit方式半同步，主庫當機可能會引發主從不一致，要看binlog是否傳到了從庫
啓用加強半同步了（5.7的after_sync方式），可是從庫延遲超時自動切換成異步複製

2、預防和解決的方案有：

master:innodb_flush_log_at_trx_commit=1&sync_binlog=1
slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=1
設置從庫庫爲只讀模式
可使用5.7加強半同步避免數據丟失等
binlog row格式
必須引按期的數據校驗機制
當使用延遲複製的時候，此時主從數據也是不一致的（計劃內），但在切換中，不要把延遲從提高爲主庫哦~
mha在主從切換的過程當中，因主庫系統宕機，可能形成主從不一致（mha自己機制致使這個問題）

2018年6月11日，週一

你爲何會決定進行分庫分表，分庫分表過程當中遇到什麼難題，如何解決的？

1、爲何決定進行分庫分表？

根據業務類型，和業務容量的評估，來選擇和判斷是否使用分庫分表
當前數據庫本事具備的能力，壓力的評估
數據庫的物理隔離，例如減小鎖的爭用、資源的消耗和隔離等
熱點表較多,而且數據量大，可能會致使鎖爭搶，性能降低
數據庫的高併發，數據庫的讀寫壓力過大，可能會致使數據庫或系統宕機
數據庫（MySQL5.7如下）鏈接數太高，會增長系統壓力
單表數據量大，如SQL使用不當，會致使io隨機讀寫比例高。查詢慢（大表上的B+樹太大，掃描太慢，甚至可能須要4層B+樹）
備份和恢復時間比較長

2、都遇到什麼問題?

全局pk（主鍵和惟一索引）的衝突檢測不許確，全局的自增主鍵支持不夠好
分片鍵的選擇。如沒有選擇好，可能會影響SQL執行效率
分佈式事務，中間價產品對分佈式事務的支持力度
對於開發來講，須要進行業務的拆分
對於開發來講，部分SQL不兼容則須要代碼重構，工做量的評估
對於開發來講，跨庫join，跨庫查詢

3、如何解決?

使用全局分號器。或者使用全局惟一id，（應用生成順序惟一int類型作爲全局主鍵）
應用層來判斷惟一索引
配合應用選擇合適的分片鍵，並加上索引
配合應用，配合開發，對不兼容SQL的進行整改

2018年6月12日，週二

MySQL高可用架構應該考慮什麼? 你認爲應該如何設計？

1、MySQL高可用架構應該考慮什麼？

對業務的瞭解，須要考慮業務對數據庫一致性要求的敏感程度，切換過程當中是否有事務會丟失
對於基礎設施的瞭解，須要瞭解基礎設施的高可用的架構。例如單網線，單電源等狀況
對於數據庫故障時間掌握，業務方最多能容忍時間範圍，由於高可用切換致使的應用不可用時間
須要瞭解主流的高可用的優缺點：例如 MHA/PXC/MGR 等。
考慮多IDC多副本分佈，支持IDC級別節點所有掉線後，業務能夠切到另外一個機房

2、你認爲應該如何設計?

基礎層和基礎運維部門配合，瞭解和避免網絡/ 硬盤/ 電源等是否會出現單點故障
應用層和應用開發同窗配合，在關鍵業務中記錄SQL日誌，能夠作到即便切換，出現丟事務的狀況，也能夠經過手工補的方式保證數據一致性，例如：交易型的業務引入狀態機，事務狀態，應對數據庫切換後事務重作
業務層瞭解本身的應用，根據不一樣的應用制定合理的高可用策略。
單機多實例環境及基於虛擬機或容器的設計不能分佈在同一臺物理機上。
最終大招在數據庫不可用，能夠把已說起的事務先存儲到隊列或者其餘位置，等數據庫恢復，從新應用

2018年6月13日，週三

MySQL備份，使用xtrabackup備份全實例數據時，會形成鎖等待嗎？那麼若是使用mysqldump進行備份呢？

1、xtrabackup和mysqldump會形成鎖等待嗎？

xtrabackup會，它在備份時會產生短暫的全局讀鎖FTWL(flush table with read lock)，用於拷貝frm/MYD/MYI等文件，以及記錄binlog信息。若是MyISAM表的數據量很是大，則拷貝時間就越長，加鎖的時間也越長
mysqldump有可能會。若是隻是添加 --single-transacton 選項用於保證備份數據一致性，這時就不會產生FTWL鎖了。但一般咱們爲了讓備份文件和binlog保持一致，一般也會設置 --master-data 選項用於得到當前binlog信息，這種狀況也會短暫加鎖
數據量特別大的話，建議優先用 xtrabackup，提升備份/恢復速度。而若是數據量不是太大或者想備份單表，則建議用mysqldump了，方便邏輯恢復。各有利弊，注意其適用場景

2、xtrabackup冷知識

基於MySQL 5.6版本開發的xtrabackup，會在備份過程當中生成內部通訊文件 suspend file，用於 xtrabackup 和 innobackupex 的通訊，備份結束後文件刪除，默認文件位置 /tmp/xtrabackup_suspended
若是在備份過程當中，修改了 /tmp 的訪問權限或該文件的權限，則兩個程序間直接不能通訊，會形成 xtrabackup hang 住，正在備份的表不能正常釋放鎖，會形成鎖等待，此時須要強制 kill 掉 xtrabackup 進程

2018年6月15日，週五

MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請列出你的觀點/理由。

1、觀點A：支持MySQL存儲JSON

1.MongoDB不支持事務，而MySQL支持事務

2.MySQL相對MongoDB而言，MySQL的穩定性要優於MongoDB

3.MySQL支持多種存儲引擎

2、觀點B:支持MongoDB存儲JSON

1.從性能的角度考慮，對於JSON讀寫效率MongoDB要優於MySQL

2.MongoDB相對MySQL而言，MongoDB的擴展性要優於MySQL

3.MongoDB支持更多的JSON函數

3、總結

1.若是應用程序無事務要求，存儲數據表結構複雜而且常常被修改，例如遊戲中裝備等場景用MongoDB比較適合

2.若是應用程序有事務要求，存儲數據的"表"之間相互有關聯，例若有訂單系統等場景用MySQL比較適合

3.總體來看相對看好MySQL的JSON功能，在將來官方的努力下MySQL的JSON功能有機會反超MongoDB

2018年6月17日，週日

當數據被誤刪除/誤操做後形成數據丟失。你嘗試過用什麼手段來挽救數據/損失？

1、前提
1.當數據被誤刪除/誤操做後，第一時間要關閉數據庫。業務方須要緊急掛停機公告，避免數據二次污染，用於保護數據的一致性

2.BINLOG格式爲ROW格式，不討論其餘格式的BINLOG

2、數據被誤操做(update/delete/drop)形成數據丟失，能夠用哪些手段來恢復？

1.BINLOG恢復：可使用逆向解析BINLOG工具來恢復。例如：binlog2SQL等

2.延遲從庫: 能夠經過解除延遲從庫，並指定BINLOG結束位置點，能夠實現數據恢復

3、數據被誤刪除(rm/物理文件損壞)形成數據丟失，能夠用哪些手段來恢復？

1.若是有備份，能夠經過備份恢復 mysqldump/xtrabackup + binlog 來實現全量+增量恢復

2.若是無備份可是有從庫，能夠經過主從切換，提高從庫爲主庫，從而實現數據恢復

3.若是無備份而且無從庫，但MySQL沒有重啓，能夠經過拷貝/proc/$pid/fd中的文件，來進行嘗試恢復

4.若是無備份而且無從庫，但MySQL有重啓，能夠經過extundelete或undrop-for-innodb來恢復

2018年6月19日，週二

MySQL 5.7的複製架構,在有異步複製、半同步、加強半同步、MGR等的生產中，該如何選擇？

1、生產環境中：

幾種複製場景都有存在的價值。下面分別描述一下：

從成熟度上來選擇，推薦：異步複製(GTID+ROW)
從數據安全及更高性能上選擇：加強半同步（在這個結構下也能夠把innodb_flush_log_trx_commit調整到非1，從而得到更好的性能)
對於主從切換控制覺的很差管理，又對數據一致性要求特別高的場景，可使用MGR

2、理由：

異步複製，相對來說很是成熟，對於環境運維也比較容易上手
加強半同步複製，能夠安全的保證數據傳輸到從庫上，對於單節點的配置上不用要求太嚴格，特別從庫上也能夠更寬鬆一點，並且在一致性和性能有較高的提高，但對運維上有必定的要求
MGR組複製。相對加強半同步複製，MGR更能確保數據的一致性，事務的提交，必須通過組內大多數節點（n/2+1）決議並經過，才能得以提交。MGR架構對運維難度要更高，不過它也更完美

總的來說，從技術實現上來看：MGR> 加強半同步>異步複製。

將來可能見到更多的MGR在生產中使用，對於MySQL的運維的要求也會更上一層樓。

2018年6月20日，週三

爲何說pt-osc可能會引發主從延遲，有什麼好辦法解決或規避嗎？

若複製中binlog使用row格式，對大表使用pt-osc把數據從舊錶拷貝到臨時表，期間會產生大量的binlog，從而致使延時
pt-osc在搬數據過程當中insert...select是有行鎖的，會下降事務並行度；且pt-osc搬數據過程當中生成的binlog不是並行的，因此在slave不能並行回放
能夠經過設定參數 --chunk-size、--chunk-time控制每次拷貝數據大小，也能夠設定--max-log、check-interval、check-slave-lag等參數控制主從複製延遲程度（但這樣可能會形成pt-osc工做耗時過久，須要自行權衡）

2018年6月21日，週四

你遇到過哪些緣由形成MySQL異步複製延遲？

master上多爲併發事務，salve上則多爲單線程回放（MySQL 5.7起，支持真正的並行回放，有所緩解）
異步複製，原本就是有必定延遲的（不然也不叫作異步了，介意的話能夠改爲半同步複製）
slave機器通常性能比master更弱（這是很常見的誤區，其實slave對機器性能要求並不低）
有時爲了節省機器資源，會在slave上運行多個實例
表結構設計不合理，尤爲是在MySQL 5.6以前沒主鍵，幾乎會形成全部更新都全表掃描一遍，效率很是低
slave上運行大量只讀低效率的SQL
大量大事務，也會形成slave沒法並行回放
業務設計缺陷，或網絡延遲等致使延遲

2018年6月22日，週五

MySQL天天產生了多大容量的binlog，用SQL語句能查到嗎？

首先，這是個假設性命題（又一個釣魚題）。
這個需求徹底能夠經過系統層命令，配合MySQL中的「FLUSH BINARY LOGS」快速完成。
運行SHOW MASTER/BINARY LOGS命令能查看所有binlog列表，但沒辦法區別哪些是當天內生成的。

2018年6月23日，週六

用什麼方法能夠防止誤刪數據？

如下幾個措施能夠防止誤刪數據，以下：

生產環境中，業務代碼儘可能不明文保存數據庫鏈接帳號密碼信息
重要的DML、DDL經過平臺型工具自動實施，減小人工操做
部署延遲複製從庫，萬一誤刪除時用於數據回檔，且從庫設置爲read-only
確認備份制度及時有效
啓用SQL審計功能，養成良好SQL習慣
啓用 sql_safe_updates 選項，不容許沒 WHERE 條件的更新/刪除
將系統層的rm改成mv
線上不進行物理刪除，改成邏輯刪除（將row data標記爲不可用）
啓用堡壘機，屏蔽高危SQL
下降數據庫中普通帳號的權限級別
務必開啓binlog

2018年6月24日，週日

MySQL 8.0相對於5.7的複製改進，都有哪些呢？

宋利兵老師：《MySQL 8.0相對於5.7的複製改進》的公開課也討論了這個命題，簡單歸納主要有兩部分：

1、普通複製功能改進

新增WRITESET並行複製模式，提升並行度，下降延遲
在多源複製中，可在線動態修改每一個channel的filter rule，而且能在P_S中查看/監控
Binary Log中存儲更多元數據，並支持毫秒級別的延遲監控
對JSON Documents的複製效率更高了
支持DDL Crashsafe
增長caching_sha2_password安全策略，提升複製安全性

2、MGR功能改進:

支持設置節點權重，且權重最大的在線節點將被選舉爲主
每一個節點中存儲更多的狀態信息，如版本、角色等
可根據從節點的事務狀態，自動化流控
離開集羣的服務器自動被設置爲read only，避免被誤操做更新數據
可監控MGR的內存使用狀況

2018年6月25日，週一

跑truncate table，4億條數據會不會形成長時間鎖表呢?有什麼更好的方法嗎?

最好是create新表，而後交叉rename對調，再drop/truncate table或其餘方式清除數據。

1、可操做步驟：

建立新的 tmp 表，正式表與tmp表表名交換（注意在一個SQL裏完成，並鎖表）
對 tmp 表建立硬連接 ln tmp.ibd tmp.ibd.hdlk
mysql中刪除表tmp（truncate / drop 都行）
而後找個業務不繁忙的時間刪除數據文件或者用coreutils 的truncate慢慢搞

2、關於truncate table，官檔解釋：

Logically, TRUNCATE TABLE is similar to a DELETE statement that deletes all rows, or a sequence of DROP TABLE and CREATE TABLE statements
When a table is truncated, it is dropped and re-created in a new .ibd file, and the freed space is returned to the operating system

2018年6月26日，週二

明明有個索引「感受」應該被選中，EXPLAIN時在possible_keys也有它，但最後沒被選中，可能的緣由有哪些？

1、執行計劃以下：

desc select * from t1 where c2 >= 2;
key: NULL
key_len: NULL
rows: 14
filtered: 92.86
Extra: Using where

2、可能的緣由以下：

隱式轉換
表碎片，由於表的碎片率太高
根據索引讀取到的數據在整個表中的數據佔比超過30%
統計信息沒有及時更新

3、上述執行計劃的結果是：

預計掃描的行數爲14行，filtered（是指返回結果的行佔須要讀到的行的百分比）的值爲92%。

當前執行計劃中filtered值92% 說明根據索引查詢獲取的結果佔整張表的92%，在MySQL中根據索引查詢的結果佔整張表的數據30%則不會走索，因此不會走索引。
另外，也有多是表的碎片率太高或隱式轉換致使的。

2018年6月27日，週三

主從複製線程均正常（爲Yes，也沒報錯），Master的binlog已到binlog.000100，但slave上看到Master_Log_File卻只到binlog.000090，可能的緣由有哪些?

首先要注意，這是Master_Log_File IO線程延遲，並非Relay_Master_Log_File SQL線程延遲。

1、可能的緣由以下：

因爲sync_relay_log值太低，致使Slave頻繁刷新relay_log文件，使 Slave的硬盤資源消耗太高，因此致使SlaveIO Thread很慢。
Master/Slave壓力過大致使Slave IO Thread不能及時響應，沒法及時得到Master的event。
網絡丟包嚴重。小包能夠鏈接而且保持鏈接不斷，可是大包就沒法發送。多是Master和Slave關於TCP MTU值設置不一致致使。
Master和Slave網絡連接已經斷開。但slave_net_timeout值等於0（表示徹底禁用心跳）或者slave_net_timeout和Slave_heartbeat_period很是大（表示檢測主從心跳的時間）。
Master的binlog很是大，io線程的file很長時間都在讀同一個。

2、總結
本次案例是在主庫進行壓力測試，在壓力測試的過程當中，由於Master自己的壓力就很大Master來不及把binlog發送給Slave。因此表面上看起來沒有延遲，但實際上已經產生了延遲。

。
2018年7月4日，週三

如何優化Linux操做系統用於MySQL環境？

1、初級玩法

1. 在BIOS及內核層面關閉NUMA

2. 在BIOS層面將CPU、內存均設置最大性能模式

3. 在BIOS層面關閉CPU節能模式

4. 修改IO Scheduler爲deadline 或 noop

5. 使用xfs文件系統，掛載選項noatime、nodiratime、nobarrier

6. 在內核層面設置vm.swappiness<=5，vm.dirty_ratio<=10， vm.dirty_background_rati<=5

7. 在內核層面修改用戶可最大打開文件數和線程數爲65535

8. 禁用SWAP分區

2、高端玩法

1. 使用最新穩定Linux發行版

2. 升級各個硬件設備到最新穩定firmware版本

3. 使用SSD時，開啓TRIM功能，而且能夠的話文件系統block size和SSD對齊

4. 當磁盤I/O存在瓶頸時，除了常規因素外，還須要關注中斷不均衡的可能性

2018年7月5日，週四

MySQL 8.0 InnoDB哪些新特性你最期待，爲何？

1. 數據字典所有采用InnoDB引擎存儲，支持DDL原子性、crash safe，metadata管理更完善

2. 快速在線加新列（騰訊互娛DBA團隊貢獻）
3. 並行redo log，並提高redo log的I/O性能
4. 新增倒序索引
5. 加強CBO特性
6. 消除了buffer pool mutex（Percona的貢獻）
7. 自增ID持久化
8. 行鎖增長SKIP LOCKED和NOWAIT特性選項
9. 新增事務CATS特性，大大提高事務性能（Michigan大學貢獻）
10. memcached plugin加強
11. 加強JSON性能、功能
12. 新增智能選項 innodb_dedicated_server

2018年7月10日，週二

MySQL hang的緣由有哪些？

1. MySQL使用資源太高致使服務器太累扛不住。例如CPU、內存、 I/O等開銷。

2. 磁盤無可用空間。

3. MySQL頻繁的建立和銷燬鏈接。

4. MySQL使用的最大文件打開數和鏈接數，超過了操做系統的限制。

5. MySQL的鎖不能有效的釋放。例如持有行鎖或者表鎖，形成了MDL等待。

6. MySQL的bug致使的。

致使MySQL hang住的緣由有不少，不侷限於上述因素，還須要機智的你來挖掘。

2018年7月12日，週四

專訪王曉偉老師，MySQL數據導入數據倉庫（Hadoop）有哪幾種方式？

1. 傳統方式，採用mysqldump等工具將數據文件上傳至HDFS