互聯(lián)網(wǎng)金融在分布式數(shù)據(jù)庫的運(yùn)維實(shí)踐

1、 互聯(lián)網(wǎng)金融在分布式數(shù)據(jù)庫的運(yùn)維實(shí)踐為什么選擇了MariaDB 分布式數(shù)據(jù)庫？1、 業(yè)務(wù)上子查詢SQL過多，需要大量改寫為join關(guān)聯(lián)查詢語句，開發(fā)需要更改代碼在MariaDB 5.3版本里，就已經(jīng)對子查詢進(jìn)行了優(yōu)化，并采用semi join半連接方式將SQL改寫為了表關(guān)聯(lián)join，從而提高了查詢速度。通常情況下，我們希望由內(nèi)到外，即先完成內(nèi)表里的查詢結(jié)果，然后驅(qū)動(dòng)外查詢的表，完成最終查詢，但是MySQL 5.5會(huì)先掃描外表中的所有數(shù)據(jù)，每條數(shù)據(jù)將會(huì)傳到內(nèi)表中與之關(guān)聯(lián)，如果外表很大的話，那么性能上將會(huì)很差。案例：MySQL 5.5的子查詢執(zhí)行計(jì)劃，是將in重寫為exists我們看一下這兩個(gè)執(zhí)行

2、計(jì)劃，當(dāng)外表比較大時(shí)，第一行會(huì)掃描5000071行，改為exists寫法，它的執(zhí)行計(jì)劃和in是完全一樣的。如果你外表比較大的話，查詢性能會(huì)是非常差的。案例：MariaDB 10.0的子查詢執(zhí)行計(jì)劃，是將in/exists重寫為joinMariaDB 10.0相當(dāng)于MySQL5.6版本，這里In和exists，它會(huì)直接重寫為join關(guān)聯(lián)查詢，這里有三個(gè)不同的寫法，執(zhí)行計(jì)劃是完全一樣的。改寫join以后是由小表關(guān)聯(lián)大表，可以看下掃描的行數(shù)為10行，執(zhí)行效率就是非常快的。2、由于數(shù)據(jù)量上TB，直接升級MySQL5.6，不能平滑升級，需要進(jìn)行一次mysqldump再導(dǎo)入，耗費(fèi)過多的時(shí)間。以MySQL5

3、.5版本為例，若要升級到MySQL5.6，需要進(jìn)行一次全庫mysqldump導(dǎo)出再導(dǎo)入，當(dāng)數(shù)據(jù)庫很大時(shí)，比如100GB，升級起來會(huì)非常困難。但如果升級為MariaDB10，會(huì)非常輕松，按照官方文檔闡述，只需把MySQL卸載掉，并用MariaDB啟動(dòng)，然后通過mysql_upgrade命令升級即可完成。MariaDB跟MySQL在絕大多數(shù)方面是兼容的，對于前端應(yīng)用（比如PHP、Perl、Python、Java、.NET、MyODBC、Ruby、MySQL C connector）來說，幾乎感覺不到任何不同。升級到MariaDB 10注意事項(xiàng)在處理內(nèi)部的臨時(shí)表，MariaDB 5.5/10.0用A

4、ria引擎代替了MyISAM引擎，這將使某些GROUP BY和DISTINCT請求速度更快，因?yàn)锳ria有比MyISAM更好的緩存機(jī)制。如果你的臨時(shí)表很多的話，要增加aria_pagecache_buffer_size參數(shù)的值（緩存數(shù)據(jù)和索引），默認(rèn)是128MB（ 而不是tmp_table_size 參數(shù)）。如果你沒有MyISAM表的話，建議把key_buffer_size調(diào)低，例如64KB，僅僅提供給MySQL庫里面的系統(tǒng)表使用。官方推薦使用jemalloc內(nèi)存管理器獲取更好的性能。Jemalloc內(nèi)存管理器性能上圖是官方的壓力測試報(bào)告，可以看出Jemalloc內(nèi)存管理器的性能是最好的。這是

5、之前我給MariaDB作者寫的一封信，他回答，升級到MariaDB是沒有問題的，現(xiàn)在很多大公司都用MariaDB，例如Google、Wikipedia。主要原因我總結(jié)如下：在Oracle控制下的MySQL有兩個(gè)問題：MySQL核心開發(fā)團(tuán)隊(duì)是封閉的，完全沒有Oracle之外的成員參加。很多高手即使有心做貢獻(xiàn)，也沒辦法做到。MySQL新版本的發(fā)布速度，在Oracle收購Sun之后大為減緩。這里再說一下MariaDB企業(yè)版和社區(qū)版的區(qū)別：企業(yè)版更注重bug的修復(fù)，社區(qū)版則對新功能更新比較快。MariaDB社區(qū)版和企業(yè)版的源代碼都是開源的，并且所有功能都是免費(fèi)開放，不用擔(dān)心功能上有閹割，但甲骨文MyS

6、QL企業(yè)版延伸套件采取封閉源代碼且需要付費(fèi)。此外，MariaDB相比MySQL擁有更多的功能、更快、更穩(wěn)定、BUG修復(fù)更快。3、解決復(fù)制延遲，開啟多線程并行復(fù)制（MariaDB 10.0.X基于表）金融公司對數(shù)據(jù)一致性要求較高，主從同步延遲問題是不能接受的。MySQL5.6由于是基于庫級別的并行復(fù)制，在實(shí)際生產(chǎn)中用處并不大，而只有5.7才支持基于表的并行復(fù)制。MariaDB的并行復(fù)制有兩種實(shí)現(xiàn)模式：第一種：Conservative mode of in-order parallel replication（保守模式的順序并行復(fù)制）MariaDB 10 通過基于表的多線程并行復(fù)制技術(shù)，如果主庫上

7、1秒內(nèi)有10個(gè)事務(wù)，那么合并一個(gè)IO提交一次，并在binlog里增加一個(gè)cid = XX 標(biāo)記，當(dāng)cid的值是一樣的話，Slave就可以進(jìn)行并行復(fù)制，通過設(shè)置多個(gè)sql_thread線程實(shí)現(xiàn)。上述cid為630的事務(wù)有2個(gè)，表示組提交時(shí)提交了2個(gè)事務(wù)，假如設(shè)置slave_parallel_threads =24（并行復(fù)制線程數(shù)，根據(jù)CPU核數(shù)設(shè)置），那么這2個(gè)事務(wù)在slave從庫上通過24個(gè)sql_thread線程進(jìn)行并行恢復(fù)。只有那些被自動(dòng)確認(rèn)為不會(huì)引起沖突的事務(wù)才會(huì)被并行執(zhí)行，以確保從庫上事務(wù)提交和主庫上事務(wù)提交順序一致。這些操作完全是透明的，無須DBA干涉。如果想控制binlog組提交數(shù)

8、量，可以通過下圖兩個(gè)參數(shù)設(shè)置。第二種模式：Out-of-order parallel replication（無序并行復(fù)制）設(shè)置SET SESSION gtid_domain_id=99具有不同gtid_domain_id域識(shí)別符可并行復(fù)制，生產(chǎn)使用場景通常是用在增加索引、增加字段上。實(shí)現(xiàn)無序并行復(fù)制，需要把GTID開啟才可以實(shí)現(xiàn)，執(zhí)行上圖所示的命令。多線程并行復(fù)制壓力測試我們可以看到，隨著并行復(fù)制線程的增加，slave從庫的TPS每秒寫入速度接近主庫。4、前期公司大數(shù)據(jù)部門剛起步，未成熟，需要借助多源復(fù)制技術(shù)（匯總前面多個(gè)業(yè)務(wù)庫），提供給BI部門、產(chǎn)品PO、金融分析師BA/MA進(jìn)行分析。適用

9、場景：實(shí)現(xiàn)數(shù)據(jù)分析部門的需求，將多個(gè)系統(tǒng)的數(shù)據(jù)匯聚到一臺(tái)服務(wù)器上進(jìn)行OLAP分析計(jì)算。MariaDB10多源復(fù)制的搭建方法如下。/kb/en/mariadb/multi-source-replication/ 創(chuàng)建通道SET default_master_connection =$connect_name; 建立同步復(fù)制CHANGE MASTER$connect_nameTOMASTER_HOST=0,MASTER_USER=repl,MASTER_PASSWORD=repl,MASTER_PORT=3306,MASTER_LOG_FILE=mysql-bin.000001,MASTER_LO

10、G_POS=4,MASTER_CONNECT_RETRY=10; 啟動(dòng)START SLAVE$connect_name;START ALL SLAVES; 停止STOP SLAVE $connect_name;STOP ALL SLAVES; 查看狀態(tài)SHOW SLAVE$connect_nameSTATUS;SHOW ALL SLAVES STATUS; 清空同步信息和日志RESET SLAVE$connect_nameALL; 刷新Relay logsFLUSH RELAY LOGS$connect_name;5、MariaDB ColumnStore（InfiniDB 4.6.2）數(shù)據(jù)倉

11、庫，用于大數(shù)據(jù)離線分析計(jì)算第五個(gè)原因就是數(shù)據(jù)量逐日增長，在InnoDB里進(jìn)行復(fù)雜SQL查詢分析是一件非常痛苦的事情，后來我選擇了MariaDB ColumnStore數(shù)據(jù)倉庫，專為分布式大規(guī)模并行處理Massively Parallel Processing（MPP）設(shè)計(jì)的列式存儲(chǔ)引擎，用它做大數(shù)據(jù)離線分析OLAP系統(tǒng)，借助ETL工具canal，實(shí)現(xiàn)抽取binlog并解析為原生態(tài)SQL文件入庫到Columnstore里。 Columnstore技術(shù)特性標(biāo)準(zhǔn)SQL協(xié)議支持Navicat/SQLyog/WebSQL等客戶端工具數(shù)據(jù)分布式存儲(chǔ)（本地化）Shard Nothing架構(gòu)分布式并行計(jì)算任務(wù)

12、并行執(zhí)行橫向擴(kuò)展Columnstore技術(shù)架構(gòu)UM模塊：SQL協(xié)議接口，接收客戶端連接訪問，推送SQL請求給PM性能模塊代為執(zhí)行，最后收集性能模塊的處理結(jié)果做數(shù)據(jù)匯總，并返回給客戶端最終查詢結(jié)果。PM模塊：負(fù)責(zé)數(shù)據(jù)的列式存儲(chǔ)，處理查詢請求，將數(shù)據(jù)提取到內(nèi)存中計(jì)算。安裝、使用及測試請參考我之前寫的文章： HYPERLINK /s?_biz=MzI4NTA1MDEwNg=&mid=2650758859&idx=1&sn=e6afc6a4a5652077c70b178151da178f&chksm=f3f9eb5ec48e62482647d6a6a45ab3fa734bed10b01caa0398c

13、9098e172aa7f06a5ed672431c&scene=21 l wechat_redirect t _blank MariaDB ColumnStore初探：安裝、使用及測試6、審計(jì)日志Audit Log互聯(lián)網(wǎng)金融公司對數(shù)據(jù)很敏感，業(yè)務(wù)從庫提供給開發(fā)等人員使用。DBA通過審計(jì)日志記錄他們操作的結(jié)果。安裝審計(jì)Audit Plugin插件：MariaDB審計(jì)日志參數(shù)：server_audit_events = CONNECT,QUERY,TABLEserver_audit_logging = ON server_audit_incl_users = hechunyangserver_au

14、dit_excl_users = sys_pmm,nagios server_audit_file_rotate_size = 10Gserver_audit_file_rotations = 500 server_audit_file_path = /data/audit/server_audit.log將審計(jì)日志抽到表里，用PHP展示出來分析。本節(jié)小結(jié)由于MySQL功能上迭代速度太慢，移步MariaDB后，撐過了業(yè)務(wù)發(fā)展高峰期2015-2016年。借助高性能三一書的原話：MariaDB和Percona有什么不同？高可用架構(gòu)當(dāng)時(shí)選型有兩個(gè)方案，一個(gè)是MHA，一個(gè)是PXC，為什么沒有選擇PXC

15、呢？有以下幾個(gè)不可抗力因素：（1）網(wǎng)絡(luò)抖動(dòng)或者機(jī)房被ARP攻擊，導(dǎo)致NODE節(jié)點(diǎn)失聯(lián)，出現(xiàn)了腦裂，怎么處理？最悲劇的是三份節(jié)點(diǎn)都同時(shí)寫，而且還沒復(fù)制過來，到底以哪份數(shù)據(jù)為準(zhǔn)？（2）硬盤壞了一塊，導(dǎo)致RAID10性能下降，會(huì)導(dǎo)致集群限流，限流的參數(shù)是wsrep_provider_options=gcs.fc_limit：待執(zhí)行隊(duì)列長度超過該值時(shí)，flow control被觸發(fā)，默認(rèn)是16。此時(shí)正處于促銷活動(dòng)情形，由于PXC的性能取決于最弱的一個(gè)NODE節(jié)點(diǎn)，數(shù)據(jù)庫連接數(shù)很容易被打滿，直接掛了。（3）業(yè)務(wù)如果有大事務(wù)，超過了wsrep_max_ws_rows、wsrep_max_ws_size這兩

16、個(gè)值，節(jié)點(diǎn)之間無法復(fù)制，造成數(shù)據(jù)不一致，怎么辦？由于集群是樂觀鎖并發(fā)控制，事務(wù)沖突的情況會(huì)在commit階段發(fā)生。如果有兩個(gè)事務(wù)在集群中不同的節(jié)點(diǎn)上對同一行寫入并提交，失敗的節(jié)點(diǎn)將回滾，應(yīng)用端JAVA/PHP返回報(bào)錯(cuò)，直接影響用戶體驗(yàn)。可參考Percona之前分享的PPT巨大的潛力在PXC架構(gòu)，貌似解決了一致性的問題，但距離成熟還有一段距離。下圖是Group Replication以及Galera Cluster集群觸發(fā)限流后，性能影響甚大。在沒有流量控制的情況下，Writer會(huì)在有限的時(shí)間內(nèi)處理大量行（來自8個(gè)客戶端，8個(gè)線程，50個(gè)并發(fā)批量插入）。隨著流量控制，情況急劇變化。Writer需

17、要很長時(shí)間才能處理明顯更小的行數(shù)/秒?？傊?，性能顯著下降。/blog/2017/08/01/group-replication-sweet-sour/（4）最主要的因素性能問題由于PXC/MariaDB Galera Cluster自身不支持VIP功能，MariaDB的解決方案是用MaxScale做七層負(fù)載均衡Proxy，由于本身性能就不如主從復(fù)制，再過一層代理，性能就更差?？蓞⒖枷聢D官方的解決方案。Galera Cluster整體架構(gòu)圖如下：信任Percona專業(yè)團(tuán)隊(duì)的選擇生產(chǎn)數(shù)據(jù)庫HA架構(gòu)MHA管理多組集群（多實(shí)例）我們公司目前為一主帶三從（其中一個(gè)從庫是做的延遲復(fù)制12小時(shí)，用pt-sl

18、ave-delay工具實(shí)現(xiàn)），高可用架構(gòu)采用開源MHA+半同步復(fù)制semi replication。延遲復(fù)制的目的怕萬一開發(fā)手抖，或者代碼寫了一個(gè)BUG，或者把一個(gè)表給刪了，通過延遲還能回來。上面是一個(gè)監(jiān)控圖，報(bào)錯(cuò)的就是延時(shí)復(fù)制從庫。生產(chǎn)庫MariaDB開啟的參數(shù)sync_binlog = 1 innodb_flush_log_at_trx_commit = 1innodb_support_xa = 1 （事務(wù)的兩階段提交）MHA架構(gòu)和MMM架構(gòu)有什么區(qū)別呢？最大的區(qū)別在于：MHA會(huì)把丟失的數(shù)據(jù)，在每個(gè)Slave節(jié)點(diǎn)上補(bǔ)齊。下面通過一幅圖來了解它的工作原理。我們可以看到，當(dāng)master宕機(jī)時(shí)，

19、MHA管理機(jī)會(huì)試圖scp丟失的那一部分binlog，然后把該binlog拷貝到最新的slave機(jī)器上，補(bǔ)齊差異的binlog并應(yīng)用。當(dāng)最新的slave補(bǔ)齊數(shù)據(jù)后，把它的relay-log拷貝到其他的slave上，識(shí)別差異并應(yīng)用。至此，整個(gè)恢復(fù)過程結(jié)束，從而保證切換后的數(shù)據(jù)是一致的。再通過下圖，可以更容易去理解整個(gè)恢復(fù)過程。MHA架構(gòu)注意事項(xiàng)1、防止網(wǎng)絡(luò)抖動(dòng)誤切換，造成數(shù)據(jù)不一致其實(shí)現(xiàn)原理為：投票機(jī)制，當(dāng)監(jiān)控管理機(jī)無法ping通和無法連接MySQL主庫，會(huì)試圖從監(jiān)控備機(jī)上去ping和連接MySQL主庫，只有雙方都連接失敗，才認(rèn)定MySQL主庫宕機(jī)。假如有一方可以連接MySQL主庫，都不會(huì)切換。參

20、數(shù)：secondary_check_script=/usr/local/bin/masterha_secondary_check -s 6 -s 9 -user=root-master_host=QCZJ-dbm -master_ip=7 -master_port=3306從切換日志里看，它先試圖用從庫111.76和111.79，去同時(shí)ping 111.77主庫，兩個(gè)都ping不通的話，才認(rèn)定主庫宕機(jī)，此時(shí)才可以進(jìn)行故障切換。如果有一個(gè)從庫能ping通主庫都不會(huì)進(jìn)行故障切換。需要留意的地方：由于masterha_secondary_check腳本寫死了端口，所以要手工修改ssh端口$ssh_u

21、ser = root unless ($ssh_user);$ssh_port = 62222 unless ($ssh_port);$master_port = 3306 unless ($master_port);2、VIP沒有采用keepalived，就是怕網(wǎng)絡(luò)抖動(dòng)問題。這里我修改了以下兩個(gè)腳本，自帶VIP，大家可以下載試用。master_ip_failover_script=/usr/local/bin/master_ip_failovermaster_ip_online_change_script=/usr/local/bin/master_ip_online_change紅色的部分

22、是修改的地方。# Hardcode stuff now until the next MHA release passes SSH info in hereMHA:ManagerUtil:exec_ssh_cmd( $new_master_ip, 62222, ip addr add 3/32 dev em2;arping -q -c 2 -U -I em2 3, undef ); （點(diǎn)擊文末【閱讀原文】進(jìn)行下載）數(shù)據(jù)庫架構(gòu)演進(jìn)隨著網(wǎng)站壯大，數(shù)據(jù)庫架構(gòu)一般會(huì)經(jīng)歷如下演進(jìn)：為什么要分庫分表？（性能+存儲(chǔ)擴(kuò)容）單個(gè)庫數(shù)據(jù)容量太大，單個(gè)DB存儲(chǔ)空間不夠單個(gè)庫表太多，查詢的時(shí)候，打開表操作也消耗系統(tǒng)資

23、源單個(gè)表容量太大，查詢的時(shí)候，掃描行數(shù)過多，磁盤IO大，查詢緩慢單個(gè)庫能承載的訪問量有限，再高的訪問量只能通過分庫分表實(shí)現(xiàn)針對爬蟲業(yè)務(wù)，并發(fā)讀寫頻率很高且對事務(wù)要求性不高，沒有聯(lián)表關(guān)聯(lián)查詢，那么就不需要考慮放入MySQL里，直接存入NOSQLMongoDB里更適合。利用MongoDB自身的Auto-Sharding分片技術(shù)實(shí)現(xiàn)，通過這種技術(shù)可以使我們非常方便的擴(kuò)展數(shù)據(jù)，從而不用讓開發(fā)更改一行代碼即可輕松實(shí)現(xiàn)數(shù)據(jù)拆分。我們這里做了分布式，集群總共是9臺(tái)機(jī)器分兩組Shard，兩個(gè)Shard組來做的。通過這個(gè)自動(dòng)分片，解決了開發(fā)不用改變原代碼了，減少日常工作。片鍵的選擇Hash based part

24、itioning可以確保數(shù)據(jù)平均分布，但是這樣會(huì)導(dǎo)致經(jīng)過哈希處理的值在各個(gè)數(shù)據(jù)塊和shard上隨機(jī)分布，進(jìn)而使制定的范圍查詢r(jià)ange query不能定位到某些shard而是在每個(gè)shard上進(jìn)行遍歷查詢。鑒于業(yè)務(wù)的實(shí)際情況，沒有范圍查詢，我們是以userId（查詢最頻繁的）字段做的Hash拆分。再說說片鍵的注意事項(xiàng)。第一，在對文檔個(gè)別字段update時(shí)，如果query部分沒有帶上shard key，性能會(huì)很差，因?yàn)閙ongos需要把這條update語句派發(fā)給所有的shard 實(shí)例，跨多個(gè)網(wǎng)絡(luò)性能就會(huì)下降。第二，當(dāng)update 的upsert參數(shù)為true時(shí)，query部分必須帶上 shard

25、 key，否則語句執(zhí)行出錯(cuò)。例：db.t1.update(,cid:7,name:D,upsert:1)第三，shard key的值不能被更改。最后再說一下數(shù)據(jù)均衡Balance注意事項(xiàng)。Balancer的穩(wěn)定性&智能性問題，Sharing的遷移發(fā)生時(shí)間不確定，chunk（數(shù)據(jù)塊）每到32M時(shí)內(nèi)部分裂并自動(dòng)balance，一旦發(fā)生數(shù)據(jù)遷移會(huì)造成整個(gè)系統(tǒng)的吞吐量急劇下降。為了應(yīng)對Sharding遷移的不確定性，我們可以強(qiáng)制指定Sharding遷移的時(shí)間點(diǎn)，具體遷移時(shí)間點(diǎn)依據(jù)業(yè)務(wù)訪問的低峰期。我們的流量低峰期是在凌晨1點(diǎn)到6點(diǎn)，那么我們可以在這段時(shí)間內(nèi)設(shè)置窗口期開啟Sharding遷移功能，允許數(shù)

26、據(jù)的遷移，其他的時(shí)間不進(jìn)行數(shù)據(jù)的遷移，從而做到對Sharding遷移的完全掌控，避免掉未知時(shí)間Sharding遷移帶來的一些風(fēng)險(xiǎn)。設(shè)置窗口期命令：use configdb.settings.update( _id : balancer , $set : activeWindow : start : 1:00, stop : 6:00 , true )數(shù)據(jù)均衡Balance監(jiān)控圖-Percona PMM觀察getmore黃顏色曲線，1:00-6:00點(diǎn)時(shí)間段正是做數(shù)據(jù)遷移。如果不設(shè)置窗口期，以我們7200轉(zhuǎn)的sas硬盤，在早高峰做數(shù)據(jù)遷移，定將影響業(yè)務(wù)穩(wěn)定。參考我之前寫的PMM監(jiān)控搭建使用文章：

27、 HYPERLINK /s?_biz=MzI4NTA1MDEwNg=&mid=2650759692&idx=2&sn=52f17d1def40b0c95bf5013afb7030fd&chksm=f3f9d799c48e5e8f1704e67468e27edc1dfb94ab4e430545f9197fe33be6c38468fbd126686b&scene=21 l wechat_redirect t _blank 安利一款運(yùn)維殺手锏，讓監(jiān)控部署不再尷尬！爬蟲整體入庫架構(gòu)圖新增數(shù)據(jù)先寫入數(shù)據(jù)庫WiredTiger里，然后馬上更新到In-Memory引擎（inMemorySizeGB = 18

28、0G），讀取時(shí)優(yōu)先在In-Memory內(nèi)存中讀取，如果數(shù)據(jù)不在則從后端WiredTiger里取數(shù)。In-Memory中的熱數(shù)據(jù)失效時(shí)間為一天，等待下次讀取時(shí)再加載。緩存失效時(shí)間設(shè)置在創(chuàng)建索引時(shí)，需要指定過期時(shí)間，參考畫紅色線部分，過期后集合里的這個(gè)文檔就會(huì)自動(dòng)刪除。這里有一個(gè)注意事項(xiàng)就是：字段必須是時(shí)間類型的。寫關(guān)注（Write Concern）1、 MongoDB默認(rèn)為異步復(fù)制，本地寫完后即返回客戶端請求。2、可以通過驅(qū)動(dòng)設(shè)置為：update($someDoc, $someUpdates, array(w =majority,j = true);?意思為同步復(fù)制機(jī)制，主庫數(shù)據(jù)寫入內(nèi)存后，還要

29、確保Journal重做日志刷入磁盤，并保證已復(fù)制到從節(jié)點(diǎn)后，才會(huì)返回更新成功，將請求返回給客戶端。讀寫分離MongoDB的Java驅(qū)動(dòng)，默認(rèn)讀寫是在Primary主節(jié)點(diǎn)上，如果想讀Secondary從節(jié)點(diǎn)，需要通過設(shè)置驅(qū)動(dòng)實(shí)現(xiàn)。節(jié)點(diǎn)動(dòng)態(tài)擴(kuò)容&一致性哈希算法節(jié)點(diǎn)擴(kuò)容過程為：數(shù)據(jù)1、2在節(jié)點(diǎn)A上，數(shù)據(jù)3、4在節(jié)點(diǎn)C上。如果增加一個(gè)節(jié)點(diǎn)B，數(shù)據(jù)1、2還在A上，只需要把數(shù)據(jù)3遷到B上，數(shù)據(jù)4仍在C上，所以只是部分?jǐn)?shù)據(jù)遷移，并不是整體數(shù)據(jù)遷移，這樣避免了雪崩的現(xiàn)象。延遲復(fù)制節(jié)點(diǎn)的必要性原因：1、開發(fā)代碼有BUG或DBA手抖，一瞬間讓你的業(yè)務(wù)回到解放前2、過TB數(shù)據(jù)備份恢復(fù)問題MariaDB 10.2才支

30、持延遲復(fù)制（MySQL5.6早已支持），固需要借助Percona PT工具實(shí)現(xiàn)shell perl /usr/local/bin/pt-slave-delay -S /tmp/mysql.sock -user root-password 123456 -delay 43200 -log /root/delay.log -daemonize注：單位秒，43200秒等于12小時(shí)MongoDB 3.2延遲復(fù)制實(shí)現(xiàn)Primary rs.add( host:qianzhan_:27017, priority:0,hidden:1,slaveDelay:43200,votes:0 )注：priority權(quán)

31、重設(shè)置為0，永遠(yuǎn)不能切為Primaryhidden設(shè)置為隱藏節(jié)點(diǎn)slaveDelay延遲時(shí)間，單位秒，43200秒等于12小時(shí)votes取消投票資格用Percona MongoDB替換原生版熱備份功能Percona MongoDB3.2版本默認(rèn)支持WiredTiger引擎的在線熱備份，解決了官方版只能通過mongodump邏輯備份這一缺陷?；謴?fù)很簡單，把備份目錄里的數(shù)據(jù)文件直接拷貝到你的dbpath下，然后啟動(dòng)MongoDB即可。參考文獻(xiàn)：/doc/percona-server-for-mongodb/LATEST/hot-backup.html#hot-backup 注：Percona se

32、rver Mongodb 3.2.10有一個(gè)bugdirectoryperdb = truewiredTigerDirectoryForIndexes = true這兩個(gè)參數(shù)必須注銷掉，否則備份失敗。這是我提交的bug地址，/browse/PSMDB-123Percona采納了該bug，并在3.2.12版本里修復(fù)。/doc/percona-server-for-mongodb/3.2/release_notes/3.2.12-3.2.htmlPercona MongoDB3.2 HotBackup Perl Scripts使用說明：請?jiān)诒镜豠dmin數(shù)據(jù)庫，以管理員身份運(yùn)行createBack

33、up命令，并指定備份目錄。自動(dòng)備份腳本# perl -MCPAN -e “install MongoDB”#!/usr/bin/perluse MongoDB;use File:Path;use POSIX qw(strftime);my $mc = MongoDB:MongoClient-new( host = mongodb:/localhost:37019/, username = admin, password = 123456,);my $db = $mc-get_database(admin);$year = strftime %Y,localtime;$month = strft

34、ime %m,localtime;$time = strftime %Y-%m-%d-%H-%M-%S, localtime;$BAKDB = yourdb;$BAKDIR = /data/bak/hcy/$year/$month/$BAKDB_$time;my $user = getpwnam mongodb or die bad user;my $group = getgrnam mongodb or die bad group;mkpath($BAKDIR) or die 目錄已存在. $!;chown $user, $group, $BAKDIR;my $cmd = createBac

35、kup = 1, backupDir = $BAKDIR;$db-run_command($cmd);if($! = 0) print backup is success.;else print backup is failure.;MongoDB 慢查詢郵件報(bào)警并自動(dòng)KILL Perl Scripts通過查看當(dāng)前操作db.currentOp()，大于指定執(zhí)行時(shí)間，發(fā)郵件報(bào)警，并通過db.killOp(opid)殺掉進(jìn)程。（點(diǎn)擊文末【閱讀原文】即可下載）Oplog蓋子集合(Capped Collections)注意事項(xiàng)（可以理解為MySQL Binlog）默認(rèn)剩余空間的5% 當(dāng)你搭建副本集的時(shí)

36、候，一定要把Oplog設(shè)置得比較大，默認(rèn)是剩余磁盤空間的5%，我們線上設(shè)置為100G。Oplog跟binlog存儲(chǔ)方式不太一樣，binlog是寫滿一個(gè)文件會(huì)再生成一個(gè)新的文件繼續(xù)寫，而Oplog則是覆蓋寫。我們看上圖，從庫掛掉以后再次加入集群時(shí)，它會(huì)先發(fā)送一個(gè)位置點(diǎn)給主庫，比如現(xiàn)在發(fā)送一個(gè)位置點(diǎn)是27，主庫有的話會(huì)把27之后的數(shù)據(jù)推過來。如主庫沒有會(huì)告知從庫我這里沒有找到，從庫會(huì)把本地?cái)?shù)據(jù)全部刪除，從主庫上全量抽數(shù)據(jù)，學(xué)名為initial sync。神器！MongoDB語法在線生成器/可以將SQL語法轉(zhuǎn)換成MongoDB語法，例子：MySQL 分庫分表中間件選擇MariaDB Spider分庫

37、分表存儲(chǔ)引擎/kb/en/mariadb/spider-storage-engine-overview/Spider是MariaDB內(nèi)置的一個(gè)可插拔用于MariaDB/MySQL數(shù)據(jù)庫分片的存儲(chǔ)引擎，充當(dāng)應(yīng)用服務(wù)器和遠(yuǎn)程后端DB之間的代理（中間件），它可以輕松實(shí)現(xiàn)MySQL的橫向和縱向擴(kuò)展，突破單臺(tái)MySQL的限制，支持范圍分區(qū)、列表分區(qū)、哈希分區(qū)，支持XA分布式事務(wù)，支持跨庫join。通過Spider，您可以跨多個(gè)數(shù)據(jù)庫后端有效訪問數(shù)據(jù)，讓您的應(yīng)用程序一行代碼不改，即可輕松實(shí)現(xiàn)分庫分表！開發(fā)無需調(diào)整代碼，應(yīng)用層跟訪問單機(jī)MySQL一樣。DBA部署簡單，由于MariaDB10默認(rèn)已經(jīng)捆綁了Sp

38、ider引擎，無需編譯安裝。支持標(biāo)準(zhǔn)SQL語法，存儲(chǔ)過程，函數(shù)，跨庫Join，沒有Atlas那么多的限制。后端DB可以是任一版本，MySQL/MariaDB/Percona無維護(hù)成本生產(chǎn)成熟案例-騰訊公司這個(gè)是它的整體的架構(gòu)圖， 應(yīng)用程序連接Spider，Spider充當(dāng)中間件代理，將客戶端查詢的請求，按照事先定義好的分片規(guī)則，分發(fā)給后端數(shù)據(jù)庫，之后返回的數(shù)據(jù)匯總在Spider內(nèi)存里做聚合，最終返回客戶端請求，對于應(yīng)用程序而言是透明的。性能壓力測試sysbench在我的壓測結(jié)果上，分表的性能會(huì)降低70%，垂直拆分性能會(huì)降低40%，性能損耗的原因是在分布式場景下，要保證2PC一致性和可用性讀寫的表現(xiàn)就差，另外就是跨多個(gè)網(wǎng)絡(luò)傳輸這兩方面引起的。在生產(chǎn)環(huán)境中，我通過Spider實(shí)現(xiàn)了表的垂直拆分，沒有做分庫分表。使用場景介紹（架構(gòu)圖）1、交易流水表我是半年一切表，老表改名，再創(chuàng)新一張新表，然后通知開發(fā)手工改代碼里的SQL，用union all的方式關(guān)聯(lián)查詢。如：select * from t1 where apply_no = XXXX union all select * from t1_20170630 where apply_no = XXXX2、由于歷史表