国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

#目錄

• MySQL主從復(fù)制什么原因會(huì)造成不一致，如何預(yù)防及解決？

• 你為什么會(huì)決定進(jìn)行分庫(kù)分表，分庫(kù)分表過(guò)程中遇到什么難題，如何解決的？

• MySQL高可用架構(gòu)應(yīng)該考慮什么? 你認(rèn)為應(yīng)該如何設(shè)計(jì)？

• MySQL備份，使用xtrabackup備份全實(shí)例數(shù)據(jù)時(shí)，會(huì)造成鎖等待嗎？那么如果使用mysqldump進(jìn)行備份呢？

• MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請(qǐng)列出你的觀點(diǎn)/理由。

• 當(dāng)數(shù)據(jù)被誤刪除/誤操作后造成數(shù)據(jù)丟失。你嘗試過(guò)用什么手段來(lái)挽救數(shù)據(jù)/損失？

• MySQL 5.7的復(fù)制架構(gòu),在有異步復(fù)制、半同步、增強(qiáng)半同步、MGR等的生產(chǎn)中，該如何選擇？

一、MySQL主從復(fù)制什么原因會(huì)造成不一致，如何預(yù)防及解決？

（一）導(dǎo)致主從不一致的原因主要有：

1、人為原因?qū)е聫膸?kù)與主庫(kù)數(shù)據(jù)不一致（從庫(kù)寫入）

2、主從復(fù)制過(guò)程中，主庫(kù)異常宕機(jī)

3、設(shè)置了ignore/do/rewrite等replication等規(guī)則

4、binlog非row格式

5、異步復(fù)制本身不保證，半同步存在提交讀的問題，增強(qiáng)半同步起來(lái)比較完美。 但對(duì)于異常重啟（Replication Crash Safe），從庫(kù)寫數(shù)據(jù)（GTID）的防范，還需要策略來(lái)保證。

6、從庫(kù)中斷很久，binlog應(yīng)用不連續(xù)，監(jiān)控并及時(shí)修復(fù)主從

7、從庫(kù)啟用了諸如存儲(chǔ)過(guò)程，從庫(kù)禁用存儲(chǔ)過(guò)程等

8、數(shù)據(jù)庫(kù)大小版本/分支版本導(dǎo)致數(shù)據(jù)不一致？，主從版本統(tǒng)一

9、備份的時(shí)候沒有指定參數(shù) 例如mysqldump --master-data=2 等

10、主從sql_mode 不一致

11、一主二從環(huán)境，二從的server id一致

12、MySQL自增列 主從不一致

13、主從信息保存在文件里面，文件本身的刷新是非事務(wù)的，導(dǎo)致從庫(kù)重啟后開始執(zhí)行點(diǎn)大于實(shí)際執(zhí)行點(diǎn)

14、采用5.6的after_commit方式半同步，主庫(kù)當(dāng)機(jī)可能會(huì)引起主從不一致，要看binlog是否傳到了從庫(kù)

15、啟用增強(qiáng)半同步了（5.7的after_sync方式），但是從庫(kù)延遲超時(shí)自動(dòng)切換成異步復(fù)制

（二）預(yù)防和解決的方案有：

1、master:innodb_flush_log_at_trx_commit=1&sync_binlog=1

2、slave:master_info_repository=“TABLE”&relay_log_info_repository=“TABLE”&relay_log_recovery=1

3、設(shè)置從庫(kù)庫(kù)為只讀模式

4、可以使用5.7增強(qiáng)半同步避免數(shù)據(jù)丟失等

5、binlog row格式

6、必須引定期的數(shù)據(jù)校驗(yàn)機(jī)制

7、當(dāng)使用延遲復(fù)制的時(shí)候，此時(shí)主從數(shù)據(jù)也是不一致的（計(jì)劃內(nèi)），但在切換中，不要把延遲從提升為主庫(kù)哦~

8、mha在主從切換的過(guò)程中，因主庫(kù)系統(tǒng)宕機(jī)，可能造成主從不一致（mha本身機(jī)制導(dǎo)致這個(gè)問題）

二、你為什么會(huì)決定進(jìn)行分庫(kù)分表，分庫(kù)分表過(guò)程中遇到什么難題，如何解決的？

（一）為什么決定進(jìn)行分庫(kù)分表？

1.根據(jù)業(yè)務(wù)類型，和業(yè)務(wù)容量的評(píng)估，來(lái)選擇和判斷是否使用分庫(kù)分表

2.當(dāng)前數(shù)據(jù)庫(kù)本事具有的能力，壓力的評(píng)估

3.數(shù)據(jù)庫(kù)的物理隔離，例如減少鎖的爭(zhēng)用、資源的消耗和隔離等

4.熱點(diǎn)表較多,并且數(shù)據(jù)量大，可能會(huì)導(dǎo)致鎖爭(zhēng)搶，性能下降

5.數(shù)據(jù)庫(kù)的高并發(fā)，數(shù)據(jù)庫(kù)的讀寫壓力過(guò)大，可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)或系統(tǒng)宕機(jī)

6.數(shù)據(jù)庫(kù)（MySQL5.7以下）連接數(shù)過(guò)高，會(huì)增加系統(tǒng)壓力

7.單表數(shù)據(jù)量大，如SQL使用不當(dāng)，會(huì)導(dǎo)致io隨機(jī)讀寫比例高。查詢慢（大表上的B+樹太大，掃描太慢，甚至可能需要4層B+樹）

8.備份和恢復(fù)時(shí)間比較長(zhǎng)

（二）都遇到什么問題?

1.全局pk（主鍵和唯一索引）的沖突檢測(cè)不準(zhǔn)確，全局的自增主鍵支持不夠好

2.分片鍵的選擇。如沒有選擇好，可能會(huì)影響SQL執(zhí)行效率

3.分布式事務(wù)，中間價(jià)產(chǎn)品對(duì)分布式事務(wù)的支持力度

4.對(duì)于開發(fā)來(lái)說(shuō)，需要進(jìn)行業(yè)務(wù)的拆分

5.對(duì)于開發(fā)來(lái)說(shuō)，部分SQL不兼容則需要代碼重構(gòu)，工作量的評(píng)估

6.對(duì)于開發(fā)來(lái)說(shuō)，跨庫(kù)join，跨庫(kù)查詢

（三）如何解決?

1.使用全局分號(hào)器?；蛘呤褂萌治ㄒ籭d，（應(yīng)用生成順序唯一int類型做為全局主鍵）

2.應(yīng)用層來(lái)判斷唯一索引

3.配合應(yīng)用選擇合適的分片鍵，并加上索引

4.配合應(yīng)用，配合開發(fā)，對(duì)不兼容SQL的進(jìn)行整改

三、MySQL高可用架構(gòu)應(yīng)該考慮什么? 你認(rèn)為應(yīng)該如何設(shè)計(jì)？

（一）MySQL高可用架構(gòu)應(yīng)該考慮什么？

1.對(duì)業(yè)務(wù)的了解，需要考慮業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)一致性要求的敏感程度，切換過(guò)程中是否有事務(wù)會(huì)丟失

2.對(duì)于基礎(chǔ)設(shè)施的了解，需要了解基礎(chǔ)設(shè)施的高可用的架構(gòu)。例如 單網(wǎng)線，單電源等情況

3.對(duì)于數(shù)據(jù)庫(kù)故障時(shí)間掌握，業(yè)務(wù)方最多能容忍時(shí)間范圍，因?yàn)楦呖捎们袚Q導(dǎo)致的應(yīng)用不可用時(shí)間

4.需要了解主流的高可用的優(yōu)缺點(diǎn)：例如 MHA/PXC/MGR 等。

5.考慮多IDC多副本分布，支持IDC級(jí)別節(jié)點(diǎn)全部掉線后，業(yè)務(wù)可以切到另一個(gè)機(jī)房

（二）你認(rèn)為應(yīng)該如何設(shè)計(jì)?

1.基礎(chǔ)層 和基礎(chǔ)運(yùn)維部門配合，了解和避免網(wǎng)絡(luò)/ 硬盤/ 電源等是否會(huì)出現(xiàn)單點(diǎn)故障

2.應(yīng)用層 和應(yīng)用開發(fā)同學(xué)配合，在關(guān)鍵業(yè)務(wù)中記錄SQL日志，可以做到即使切換，出現(xiàn)丟事務(wù)的情況，也可以通過(guò)手工補(bǔ)的方式保證數(shù)據(jù)一致性，例如：交易型的業(yè)務(wù)引入狀態(tài)機(jī)，事務(wù)狀態(tài)，應(yīng)對(duì)數(shù)據(jù)庫(kù)切換后事務(wù)重做

3.業(yè)務(wù)層 了解自己的應(yīng)用，根據(jù)不同的應(yīng)用制定合理的高可用策略。

4.單機(jī)多實(shí)例 環(huán)境及基于虛擬機(jī)或容器的設(shè)計(jì)不能分布在同一臺(tái)物理機(jī)上。

5.最終大招 在數(shù)據(jù)庫(kù)不可用 ，可以把已提及的事務(wù)先存儲(chǔ)到隊(duì)列或者其他位置，等數(shù)據(jù)庫(kù)恢復(fù)，重新應(yīng)用

四、MySQL備份，使用xtrabackup備份全實(shí)例數(shù)據(jù)時(shí)，會(huì)造成鎖等待嗎？那么如果使用mysqldump進(jìn)行備份呢？

（一）xtrabackup和mysqldump會(huì)造成鎖等待嗎？

1.xtrabackup會(huì)，它在備份時(shí)會(huì)產(chǎn)生短暫的全局讀鎖FTWL(flush table with read lock)，用于拷貝frm/MYD/MYI等文件，以及記錄binlog信息。如果MyISAM表的數(shù)據(jù)量非常大，則拷貝時(shí)間就越長(zhǎng)，加鎖的時(shí)間也越長(zhǎng)

2.mysqldump有可能會(huì)。如果只是添加 --single-transacton 選項(xiàng)用于保證備份數(shù)據(jù)一致性，這時(shí)就不會(huì)產(chǎn)生FTWL鎖了。但通常我們?yōu)榱俗寕浞菸募蚥inlog保持一致，通常也會(huì)設(shè)置 --master-data 選項(xiàng)用于獲得當(dāng)前binlog信息，這種情況也會(huì)短暫加鎖

3.數(shù)據(jù)量特別大的話，建議優(yōu)先用 xtrabackup，提高備份/恢復(fù)速度。而如果數(shù)據(jù)量不是太大或者想備份單表，則建議用mysqldump了，方便邏輯恢復(fù)。各有利弊，注意其適用場(chǎng)景

（二）xtrabackup冷知識(shí)

1.基于MySQL 5.6版本開發(fā)的xtrabackup，會(huì)在備份過(guò)程中生成內(nèi)部通信文件 suspend file，用于 xtrabackup 和 innobackupex 的通信，備份結(jié)束后文件刪除，默認(rèn)文件位置 /tmp/xtrabackup_suspended

2.如果在備份過(guò)程中，修改了 /tmp 的訪問權(quán)限或該文件的權(quán)限，則兩個(gè)程序間直接不能通信，會(huì)造成 xtrabackup hang 住，正在備份的表不能正常釋放鎖，會(huì)造成鎖等待，此時(shí)需要強(qiáng)制 kill 掉 xtrabackup 進(jìn)程

五、MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請(qǐng)列出你的觀點(diǎn)/理由。

（一）觀點(diǎn)A：支持MySQL存儲(chǔ)JSON

1.MongoDB不支持事務(wù)，而MySQL支持事務(wù)

2.MySQL相對(duì)MongoDB而言，MySQL的穩(wěn)定性要優(yōu)于MongoDB

3.MySQL支持多種存儲(chǔ)引擎

（二）觀點(diǎn)B:支持MongoDB存儲(chǔ)JSON

1.從性能的角度考慮，對(duì)于JSON讀寫效率MongoDB要優(yōu)于MySQL

2.MongoDB相對(duì)MySQL而言，MongoDB的擴(kuò)展性要優(yōu)于MySQL

3.MongoDB支持更多的JSON函數(shù)

（三）總結(jié)

1.如果應(yīng)用程序無(wú)事務(wù)要求，存儲(chǔ)數(shù)據(jù)表結(jié)構(gòu)復(fù)雜并且經(jīng)常被修改， 例如游戲中裝備等場(chǎng)景用MongoDB比較適合

2.如果應(yīng)用程序有事務(wù)要求，存儲(chǔ)數(shù)據(jù)的'表'之間相互有關(guān)聯(lián)，例如有訂單系統(tǒng)等場(chǎng)景用MySQL比較適合

3.整體來(lái)看相對(duì)看好MySQL的JSON功能，在未來(lái)官方的努力下MySQL的JSON功能有機(jī)會(huì)反超MongoDB

六、當(dāng)數(shù)據(jù)被誤刪除/誤操作后造成數(shù)據(jù)丟失。你嘗試過(guò)用什么手段來(lái)挽救數(shù)據(jù)/損失？

（一）前提

1.當(dāng)數(shù)據(jù)被誤刪除/誤操作后，第一時(shí)間要關(guān)閉數(shù)據(jù)庫(kù)。業(yè)務(wù)方需要緊急掛停機(jī)公告，避免數(shù)據(jù)二次污染，用于保護(hù)數(shù)據(jù)的一致性

2.BINLOG格式為ROW格式，不討論其他格式的BINLOG

（二）數(shù)據(jù)被誤操作(update/delete/drop)造成數(shù)據(jù)丟失，可以用哪些手段來(lái)恢復(fù)？

1.BINLOG恢復(fù)：可以使用逆向解析BINLOG工具來(lái)恢復(fù)。例如：binlog2SQL等

2.延遲從庫(kù): 可以通過(guò)解除延遲從庫(kù)，并指定BINLOG結(jié)束位置點(diǎn)，可以實(shí)現(xiàn)數(shù)據(jù)恢復(fù)

（三）數(shù)據(jù)被誤刪除(rm/物理文件損壞)造成數(shù)據(jù)丟失，可以用哪些手段來(lái)恢復(fù)？

1.如果有備份，可以通過(guò)備份恢復(fù) mysqldump/xtrabackup + binlog 來(lái)實(shí)現(xiàn)全量+增量恢復(fù)

2.如果無(wú)備份但是有從庫(kù)，可以通過(guò)主從切換，提升從庫(kù)為主庫(kù)，從而實(shí)現(xiàn)數(shù)據(jù)恢復(fù)

3.如果無(wú)備份并且無(wú)從庫(kù)，但MySQL沒有重啟，可以通過(guò)拷貝/proc/$pid/fd中的文件，來(lái)進(jìn)行嘗試恢復(fù)

4.如果無(wú)備份并且無(wú)從庫(kù)，但MySQL有重啟，可以通過(guò)extundelete或undrop-for-innodb來(lái)恢復(fù)

七、MySQL 5.7的復(fù)制架構(gòu),在有異步復(fù)制、半同步、增強(qiáng)半同步、MGR等的生產(chǎn)中，該如何選擇？

（一）生產(chǎn)環(huán)境中：

幾種復(fù)制場(chǎng)景都有存在的價(jià)值。下面分別描述一下：

1.從成熟度上來(lái)選擇，推薦：異步復(fù)制(GTID+ROW)

2.從數(shù)據(jù)安全及更高性能上選擇：增強(qiáng)半同步 （在這個(gè)結(jié)構(gòu)下也可以把innodb_flush_log_trx_commit調(diào)整到非1， 從而獲得更好的性能)

3.對(duì)于主從切換控制覺的不好管理，又對(duì)數(shù)據(jù)一致性要求特別高的場(chǎng)景，可以使用MGR

（二）理由：

1.異步復(fù)制，相對(duì)來(lái)講非常成熟，對(duì)于環(huán)境運(yùn)維也比較容易上手

2.增強(qiáng)半同步復(fù)制，可以安全的保證數(shù)據(jù)傳輸?shù)綇膸?kù)上，對(duì)于單節(jié)點(diǎn)的配置上不用要求太嚴(yán)格，特別從庫(kù)上也可以更寬松一點(diǎn)，而且在一致性和性能有較高的提升，但對(duì)運(yùn)維上有一定的要求

3.MGR組復(fù)制。相對(duì)增強(qiáng)半同步復(fù)制，MGR更能確保數(shù)據(jù)的一致性，事務(wù)的提交，必須經(jīng)過(guò)組內(nèi)大多數(shù)節(jié)點(diǎn)（n/2+1）決議并通過(guò)，才能得以提交。MGR架構(gòu)對(duì)運(yùn)維難度要更高，不過(guò)它也更完美

總的來(lái)講，從技術(shù)實(shí)現(xiàn)上來(lái)看：MGR> 增強(qiáng)半同步>異步復(fù)制。

未來(lái)可能見到更多的MGR在生產(chǎn)中使用，對(duì)于MySQL的運(yùn)維的要求也會(huì)更上一層樓。