ShardingSphere(1)—主從篇

1、MySQL搭建主從集群

1.1、好處

數據安全

給主服務增加一個數據備份?；谶@個目的，可以搭建主從架構，或者也可以基于主從架構搭建互主的架構。

讀寫分離

MySQl的主從架構是讀寫分離的一個基礎。

讀寫分離需要第三方中間件，比如ShardingSphere，MyCat。。。

適用于讀多寫少，讀請求遠遠高于寫請求

當主服務的訪問壓力過大時，可以將數據讀請求轉為由從服務來分擔，主服務只負責數據寫入的請求，這樣大大緩解數據庫的訪問壓力。

3、故障轉移-高可用

當MySQL主服務宕機后，可以由一臺從服務切換成為主服務，繼續提供數據讀寫功能。

對于高可用架構，主從數據的同步也只是實現故障轉移的一個前提條件，要實現MySQL主從切換，還需要依靠一些其他的中間件來實現。比如MMM、MHA、MGR。

主從架構，高可用架構是必須的?。。。?！

1.2、主從同步原理

MySQL服務的主從架構一般都是通過``binlog日志文件來進行的。即在主服務上打開binlog記錄每一步的數據庫操作，然后從服務上會有一個IO線程，負責跟主服務建立一個TCP連接，請求主服務將binlog傳輸過來。這時，主庫上會有一個IOdump線程，負責通過這個TCP連接把Binlog日志傳輸給從庫的IO線程。接著從服務的IO線程會把讀取到的binlog日志數據寫入自己的relay日志文件中。然后從服務上另外一個SQL線程會讀取relay日志里的內容，進行操作重演，達到還原數據的目的。我們通常對MySQL做的讀寫分離配置就必須基于主從架構`來搭建。

1.3、binlog使用場景

主從同步

緩存數據同步

如Canal

原理：模擬一個slave節點，向MySQL發起binlog同步，然后將數據落地到Redis、Kafka等其他組件，實現數據實時流轉。

1.4、搭建要求

主從MySQL版本必須一樣

最少主服務要低于從服務

兩節點間時間要同步

1.5、搭建主從集群

1.5.1、無細節版

主：

docker run --name mysql-master --privileged=true -v /usr/local/mysql/master-data:/var/lib/mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root -d xiaochunping/mysql-master

--name指定運行之后的容器的名稱為mysql-master；

--privileged指定了當前容器是否真正的具有root權限，所謂的root權限是指具有宿主機的root權限，而不僅僅只是在容器內部有root權限；

-v指定了容器中指定目錄掛載到宿主機上的某個目錄，這樣做的目的在于防止容器中配置的數據丟失，因為docker容器在重啟之后是不會保留前一次在其內部運行的相關數據的；

-p表示宿主機上的某個端口映射到docker容器內的某個端口，這里也就是將宿主機的3306端口映射到容器內部的3306端口；

-e表示指定當前容器運行的環境變量，該變量一般在容器內部程序的配置文件中使用，而在外部運行容器指定該參數。這里的MYSQL_ROOT_PASSWORD表示容器內部的MySQL的啟動密碼；

-d參數指定了當前容器是在后臺運行。

進入容器

docker exec -it mastermysql /bin/bash

進入mysql

mysql -uroot -proot

授權

grant replication slave on . to ‘test’@’%’ identified by ‘123456’;

flush privileges;

查看binlog

show master status;

docker run --name mysql-slave --privileged=true -v /usr/local/mysql/slave-data:/var/lib/mysql -p 3307:3306 --link mysql-master:master -e MYSQL_ROOT_PASSWORD=root -d xiaochunping/mysql-slave

所映射的宿主機的端口號不能與master容器相同，因為其已經被master容器占用；

必須加上--link參數，其后指定了當前容器所要連接的容器，mysql-master表示所要連接的容器的名稱，master表示為該容器起的一個別名，通俗來講，就是slave容器通過這兩個名稱都可以訪問到master容器。這么做的原因在于，如果master與slave不在同一個docker network中，那么這兩個容器相互之間是沒法訪問的。注意這一點非常重要，之前本人按照網上的搭建方式搭建主從服務器一直無法成功，主要就是因為他們一直沒有提到要設置這個參數。

進入容器

docker exec -it mysql-slave /bin/bash

進入mysql

mysql -uroot -proot

復制master數據

change master to master_host='master', master_user='test', master_password='123456', master_port=3306, master_log_file='mysql-bin.000003', master_log_pos=589, master_connect_retry=30;

注意master_log_file為上面圖上的file，master_log_pos為Position

啟動主從復制

start slave;

查看slave

show slave status \G;

Slave_IO_Running/Slave_SQL_Running都為true，所以是成功的?。?！

master

slave

1.5.2、細節篇

首先，配置主節點的mysql配置文件： /etc/my.cnf 這一步需要對master進行配置，主要是需要打開binlog日志，以及指定severId。我們打開MySQL主服務的

my.cnf文件，在文件中一行server-id以及一個關閉域名解析的配置。然后重啟服務。

[mysqld] server-id=47 #開啟binlog log_bin=master-bin log_bin-index=master-bin.index skip-name-resolve # 設置連接端口 port=3306 # 設置mysql的安裝目錄 basedir=/usr/local/mysql # 設置mysql數據庫的數據的存放目錄 datadir=/usr/local/mysql/mysql-files # 允許最大連接數 max_connections=200 # 允許連接失敗的次數。 max_connect_errors=10 # 服務端使用的字符集默認為UTF8 character-set-server=utf8 # 創建新表時將使用的默認存儲引擎 default-storage-engine=INNODB # 默認使用“mysql_native_password”插件認證 #mysql_native_password default_authentication_plugin=mysql_native_password

配置說明：主要需要修改的是以下幾個屬性：

server-id：服務節點的唯一標識。需要給集群中的每個服務分配一個單獨的ID。

log_bin：打開Binlog日志記錄，并指定文件名。

log_bin-index：Binlog日志文件

重啟MySQL服務， service mysqld restart

然后，我們需要給root用戶分配一個replication slave的權限。

#登錄主數據庫 mysql -u root -p GRANT REPLICATION SLAVE ON *.* TO 'root'@'%'; flush privileges; #查看主節點同步狀態： show master status;

在實際生產環境中，通常不會直接使用root用戶，而會創建一個擁有全部權限的用戶來負責主從同步。

這個指令結果中的File和Position記錄的是當前日志的binlog文件以及文件中的索引。

而后面的Binlog_Do_DB和Binlog_Ignore_DB這兩個字段是表示需要記錄binlog文件的庫以及不需要記錄binlog文件的庫。目前我們沒有進行配置，就表示是針對

全庫記錄日志。這兩個字段如何進行配置，會在后面進行介紹。

開啟binlog后，數據庫中的所有操作都會被記錄到datadir當中，以一組輪詢文件的方式循環記錄。而指令查到的File和Position就是當前日志的文件和位置。而在后面配置從服務時，就需要通過這個File和Position通知從服務從哪個地方開始記錄binLog。

下一步，我們來配置從服務mysqls。 我們打開mysqls的配置文件my.cnf，修改配置文件：

[mysqld] #主庫和從庫需要不一致 server-id=48 #打開MySQL中繼日志 relay-log-index=slave-relay-bin.index relay-log=slave-relay-bin #打開從服務二進制日志 log-bin=mysql-bin #使得更新的數據寫進二進制日志中 log-slave-updates=1 # 設置3306端口 port=3306 # 設置mysql的安裝目錄 basedir=/usr/local/mysql # 設置mysql數據庫的數據的存放目錄 datadir=/usr/local/mysql/mysql-files # 允許最大連接數 max_connections=200 # 允許連接失敗的次數。 max_connect_errors=10 # 服務端使用的字符集默認為UTF8 character-set-server=utf8 # 創建新表時將使用的默認存儲引擎 default-storage-engine=INNODB # 默認使用“mysql_native_password”插件認證 # mysql_native_password default_authentication_plugin=mysql_native_password

配置說明：主要需要關注的幾個屬性：

server-id：服務節點的唯一標識

relay-log：打開從服務的relay-log日志。

log-bin：打開從服務的bin-log日志記錄。

然后我們啟動mysqls的服務，并設置他的主節點同步狀態。

# 登錄從服務 mysql -u root -proot; # 設置同步主節點： CHANGE MASTER TO MASTER_HOST='192.168.232.128', MASTER_PORT=3306, MASTER_USER='root', MASTER_PASSWORD='root', MASTER_LOG_FILE='master-bin.000004', MASTER_LOG_POS=156 GET_MASTER_PUBLIC_KEY=1; # 開啟slave start slave; # 查看主從同步狀態 show slave status; # 或者用 show slave status \G; 這樣查看比較簡潔

注意，CHANGE MASTER指令中需要指定的MASTER_LOG_FILE和MASTER_LOG_POS必須與主服務中查到的保持一致。并且后續如果要檢查主從架構是否成功，也可以通過檢查主服務與從服務之間的File和Position這兩個屬性是否一致來確定。

我們重點關注其中紅色方框的兩個屬性，與主節點保持一致，就表示這個主從同步搭建是成功的。

從這個指令的結果能夠看到，有很多Replicate_開頭的屬性，這些屬性指定了兩個服務之間要同步哪些數據庫、哪些表的配置。只是在我們這個示例中全都沒有進行配置，就標識是全庫進行同步。后面我們會補充如何配置需要同步的庫和表。

master

slave

1.5.3、從slave寫了怎么辦？（自己手殘）

如果在slave從服務上查看slave狀態，發現Slave_SQL_Running=no，就表示主從同步失敗了。這有可能

是因為在從數據庫上進行了寫操作，與同步過來的SQL操作沖突了，也有可能是slave從服務重啟后有事務回滾了。

如果是因為slave從服務事務回滾的原因，可以按照以下方式重啟主從同步：

mysql> stop slave ; mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; mysql> start slave ;

或者

mysql> stop slave ; mysql> change master to ..... (參考上面的命令) mysql> start slave ; 但是這種方式要注意binlog的文件和位置，如果修改后和之前的同步接不上，那就會丟失部分數據。所以不太常用。

1.5.4、集群搭建擴展

在Master端：在my.cnf中，可以通過以下這些屬性指定需要針對哪些庫或者哪些表記錄binlog

#需要同步的二進制數據庫名 binlog-do-db=masterdemo #只保留7天的二進制日志，以防磁盤被日志占滿(可選) expire-logs-days = 7 #不備份的數據庫 binlog-ignore-db=information_schema binlog-ignore-db=performation_schema binlog-ignore-db=sys

在Slave端：在my.cnf中，需要配置備份庫與主服務的庫的對應關系

#如果salve庫名稱與master庫名相同，使用本配置 replicate-do-db=masterdemo #如果master庫名[mastdemo]與salve庫名[mastdemo01]不同，使用以下配置[需要做映射] replicate-rewrite-db=masterdemo -> masterdemo01 #如果不是要全部同步[默認全部同步]，則指定需要同步的表 replicate-wild-do-table=masterdemo01.t_dict replicate-wild-do-table=masterdemo01.t_num

配置完成了之后，在show master status指令中，就可以看到Binlog_Do_DB和Binlog_Ignore_DB兩個參數的作用了。

主讀從寫

在MySQL主從架構中，是需要嚴格限制從服務的數據寫入的，一旦從服務有數據寫入，就會造成數據不一致。并且從服務在執行事務期間還很容易造成數據同步失敗。

如果需要限制用戶寫數據，我們可以在從服務中將read_only參數的值設為1( set global read_only=1; )。這樣就可以限制用戶寫入數據。

但是這個屬性有兩個需要注意的地方：

read_only=1設置的只讀模式，不會影響slave同步復制的功能。 所以在MySQL slave庫中設定了read_only=1后，通過 “show slave status\G” 命令查看salve狀態，可以看到salve仍然會讀取master上的日志，并且在slave庫中應用日志，保證主從數據庫同步一致；

read_only=1設置的只讀模式， 限定的是普通用戶進行數據修改的操作，但不會限定具有super權限的用戶的數據修改操作。 在MySQL中設置read_only=1后，普通的應用用戶進行insert、update、delete等會產生數據變化的DML操作時，都會報出數據庫處于只讀模式不能發生數據變化的錯誤，但具有super權限的用戶，例如在本地或遠程通過root用戶登錄到數據庫，還是可以進行數據變化的DML操作； 如果需要限定super權限的用戶寫數據，可以設置super_read_only=0。另外 如果要想連super權限用戶的寫操作也禁止，就使用"flush tables with read lock;"，這樣設置也會阻止主從同步復制！

1.5.5、其他集群方式

互為主從的互主集群

環形的主從集群

本質：

==GTID==的本質也是基于==Binlog==來實現的主從同步，只是他會基于一個==全局的事務ID==來標識同步進度。這個==GTID全局事務ID==是一個全局唯一、并且趨勢遞增的分布式ID策略。

在基于GTID的復制中，首先從服務器會告訴主服務器已經在從服務器執行完了哪些事務的GTID值，然后主庫會有把所有沒有在從庫上執行的事務，發送到從庫上進行執行，并且使用GTID的復制可以保證同一個事務只在指定的從庫上執行一次，這樣可以避免由于偏移量的問題造成數據不一致。

搭建：

master

gtid_mode=on enforce_gtid_consistency=on log_bin=on server_id=單獨設置一個 binlog_format=row

slave：

gtid_mode=on enforce_gtid_consistency=on log_slave_updates=1 server_id=單獨設置一個

然后分別重啟主服務和從服務，就可以==開啟GTID同步復制方式==。

因為已經搭了一主一從，所以一主多從的集群結構就很簡單了，增加一個binlog復制，就可以解決了??！

如果我們的集群是已經運行過一段時間，這時候如果要擴展新的從節點就有一個問題，之前的數據沒辦法從binlog來恢復了。這時候在擴展新的slave節點時，就需要增加一個數據復制的操作。

所以需要數據備份：利用mysql的bin目錄下的mysqldump工具！

mysqldump -u root -p --all-databases > backup.sql

通過這個指令，就可以將整個數據庫的所有數據導出成backup.sql，然后把這個backup.sql分發到新的MySQL服務器上，并執行下面的指令將數據全部導入到新的MySQL服務中。

新服務器

mysql -u root -p < backup.sql

這樣新的MySQL服務就已經有了所有的歷史數據，然后就可以再按照上面的步驟，配置Slave從服務的數據同步了。

主從集群，互主集群的隱患：有可能會丟數據??！

MySQL主從集群默認采用的是一種==異步復制==的機制。

主服務在執行用戶提交的事務后，寫入binlog日志，然后就給客戶端返回一個成功的響應了

binlog會由一個dump線程異步發送給Slave從服務。

因為發送的binlog是異步。主服務在向客戶端反饋執行結果時，是不知道binlog是否同步成功了的。這時候如果主服務宕機了，而從服務還沒有備份到新執行的binlog，那就有可能會丟數據。

靠MySQL的半同步復制機制來保證數據安全

半同步復制機制是一種介于異步復制和全同步復制之前的機制

主庫在執行完客戶端提交的事務后，并不是立即返回客戶端響應，而是等待至少一個從庫接收并寫到relay log中，才會返回給客戶端。MySQL在等待確認時，默認會等10秒，如果超過10秒沒有收到ack，就會降級成為異步復制。

優點：

提高數據的安全性

只保證事務提交后的binlog至少傳輸到了一個從庫，并且并不保證從庫應用這個事務的binlog是成功的！！

半同步復制機制也會造成一定程度的延遲，這個延遲時間最少是一個TCP/IP請求往返的時間

當從服務出現問題時，主服務需要等待的時間就會更長，要等到從服務的服務恢復或者請求超時才能給用戶響應

半同步復制需要基于特定的擴展模塊來實現。

這個模塊包含在mysql安裝目錄下的lib/plugin目錄下的semisync_master.so和semisync_slave.so兩個文件中。需要在主服務上安裝semisync_master模塊，在從服務上安裝semisync_slave模塊

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-9YLRvHu5-1631071303436)(https://gitee.com/zhouzhz/images/raw/master/images/image-20210903225253455.png)]

首先我們登陸主服務，安裝semisync_master模塊：

這三行指令中，第一行是通過擴展庫來安裝半同步復制模塊，需要指定擴展庫的文件名。

第二行查看系統全局參數，rpl_semi_sync_master_timeout就是半同步復制時等待應答的最長等待時間，默認是10秒，可以根據情況自行調整。

第三行則是打開半同步復制的開關。

在第二行查看系統參數時，最后的一個參數rpl_semi_sync_master_wait_point其實表示一種半同步復制的方式。

半同步復制有兩種方式，

一種是我們現在看到的這種默認的==AFTER_SYNC==方式。這種方式下，主庫把日志寫入binlog，并且復制給從庫，然后開始等待從庫的響應。從庫返回成功后，主庫再提交事務，接著給客戶端返回一個成功響應。

而另一種方式是叫做AFTER_COMMIT方式。他不是默認的。這種方式，在主庫寫入binlog后，等待binlog復制到從庫，主庫就提交自己的本地事務，再等待從庫返回給自己一個成功響應，然后主庫再給客戶端返回響應。

然后我們登陸從服務，安裝smeisync_slave模塊

slave端的安裝過程基本差不多，不過要注意下安裝完slave端的半同步插

件后，需要重啟下slave服務。

數據往主服務寫，而讀數據在從服務讀

面向業務的主服務數據都是多線程并發寫入的，而從服務是單個線程慢慢拉取binlog，這中間就會有個效率差。

所以解決這個問題的關鍵是要讓從服務也用多線程并行復制binlog數據。

MySQL自5.7版本后就已經支持并行復制了?？梢栽趶姆丈显O置slave_parallel_workers為一個大于0的數，然后把slave_parallel_type參數設置為LOGICAL_CLOCK，這就可以了。

1.5.6、MySQL的高可用方案

下面三種方案的共同點：

對主從復制集群中的Master節點進行監控

自動的對Master進行遷移，通過VIP。

重新配置集群中的其它slave對新的Master進行同步

MMM(Master-Master replication managerfor Mysql，Mysql主主復制管理器)是一套由Perl語言實現的腳本程序，可以對mysql集群進行監控和故障遷移。他需要兩個Master，同一時間只有一個Master對外提供服務，可以說是主備模式。

他是通過一個VIP(虛擬IP)的機制來保證集群的高可用。整個集群中，在主節點上會通過一個VIP地址來提供數據讀寫服務，而當出現故障時，VIP就會從原來的主節點漂移到其他節點，由其他節點提供服務。

優點：

提供了讀寫VIP的配置，使讀寫請求都可以達到高可用工具包相對比較完善，不需要額外的開發腳本完成故障轉移之后可以對MySQL集群進行高可用監控

缺點：

故障簡單粗暴，容易丟失事務，建議采用半同步復制方式，減少失敗的概率目前MMM社區已經缺少維護，不支持基于GTID的復制

適用場景：

讀寫都需要高可用的

基于日志點的復制方式

Master High Availability Manager and Tools for MySQL。是由日本人開發的一個基于Perl腳本寫的工具。這個工具專門用于監控主庫的狀態，當發現master節點故障時，會提升其中擁有新數據的slave節點成為新的master節點，在此期間，MHA會通過其他從節點獲取額外的信息來避免數據一致性方面的問題。MHA還提供了mater節點的在線切換功能，即按需切換master-slave節點。MHA能夠在30秒內實現故障切換，并能在故障切換過程中，最大程度的保證數據一致性。在淘寶內部，也有一個相似的TMHA產品。

MHA是需要單獨部署的，分為Manager節點和Node節點，兩種節點。其中Manager節點一般是單獨部署的一臺機器。而Node節點一般是部署在每臺MySQL機器上的。 Node節點得通過解析各個MySQL的日志來進行一些操作。

Manager節點會通過探測集群里的Node節點去判斷各個Node所在機器上的MySQL運行是否正常，如果發現某個Master故障了，就直接把他的一個Slave提升為Master，然后讓其他Slave都掛到新的Master上去，完全透明。

優點：

MHA除了支持日志點的復制還支持GTID的方式

同MMM相比，MHA會嘗試從舊的Master中恢復舊的二進制日志，只是未必每次都能成功。如果希望更少的數據丟失場景，建議使用MHA架構。

缺點：

MHA需要自行開發VIP轉移腳本。

MHA只監控Master的狀態，未監控Slave的狀態

MGR：MySQL Group Replication。 是MySQL官方在5.7.17版本正式推出的一種組復制機制。主要是解決傳統異步復制和半同步復制的數據一致性問題。由若干個節點共同組成一個復制組，一個事務提交后，必須經過超過半數節點的決議并通過后，才可以提交。引入組復制，主要是為了解決傳統異步復制和半同步復制可能產生數據不一致的問題。MGR依靠分布式一致性協議(Paxos協議的一個變體)，實現了分布式下數據的最終一致性，提供了真正的數據高可用方案(方案落地后是否可靠還有待商榷)。

支持多主模式，但官方推薦單主模式：

多主模式下，客戶端可以隨機向MySQL節點寫入數據

單主模式下，MGR集群會選出primary節點負責寫請求，primary節點與其它節點都可以進行讀請求處理.

優點：

基本無延遲，延遲比異步的小很多

支持多寫模式，但是目前還不是很成熟

數據的強一致性，可以保證數據事務不丟失

缺點:

僅支持innodb，且每個表必須提供主鍵。

只能用在GTID模式下，且日志格式為row格式。

適用的業務場景：

對主從延遲比較敏感

希望對對寫服務提供高可用，又不想安裝第三方軟件

數據強一致的場景

1.5.7、分庫分表

分庫分表就是業務系統將數據寫請求分發到master節點，而讀請求分發到slave節點的一種方案，可以大大提高整個數據庫集群的性能。

分庫分表的一整套邏輯全部是由客戶端自行實現的。

對于MySQL集群，數據主從同步是實現讀寫分離的一個必要前提條件。

1、解決數據量大而導致數據庫性能降低的問題

將獨立的數據庫分成若干數據庫

數據大表拆分成若干數據表（大數據量->多個小數據量）

例如

微服務架構，每個服務都分配一個獨立的數據庫（分庫）

業務日志表，按月拆分成不同的表，這就是分表。

2、數據分片解決了性能、可用性以及單點備份恢復

數據分片（將數據拆分成不同的存儲單元）

分庫

分表

分拆的角度

垂直分片（縱向分片）

核心理念：轉庫專用

在拆分之前，一個數據庫由多個數據表組成，每個表對應不同的業務。而拆分之后，則是按照業務將表進行歸類，分布到不同的數據庫或表中，從而將壓力分散至不同的數據庫或表。

列如：將用戶表和訂單表垂直分片到不同的數據庫

垂直分片往往需要對架構和設計進行調整

缺點：

無法真正的解決單點數據庫的性能瓶頸

垂直分片可以緩解數據量和訪問量帶來的問題，但無法根治

如果垂直分片之后，表中的數據量依然超過單節點所能承載的閾值，則需要水平分片來進一步處理

水平分片（橫向分片）—>分庫分表的標準方案

不根據業務邏輯分類，通過某個字段或者某幾個字段，根據某種規則將數據分散至多個庫或表中，每個分片僅包含數據的一部分。

分片策略

取余\取模 ：

優點：均勻存放數據，缺點 擴容非常麻煩

按照范圍分片 ：

比較好擴容， 數據分布不夠均勻

按照時間分片 ：

比較容易將熱點數據區分出來

按照枚舉值分片 ：

例如按地區分片

按照目標字段前綴指定進行分區：

自定義業務規則分片

兩種方式選擇

在系統設計階段就應該根據業務耦合松緊來確定垂直分庫，垂直分表方案，在數據量及訪問壓力不是特別大的情況，首先考慮緩存、讀寫分離、索引技術等方案。

若數據量極大，且持續增長，再考慮水平分庫水平分表方案

事務一致性問題

原本單機數據庫有很好的事務機制能夠幫我們保證數據一致性。但是分庫分表后，由于數據分布在不同庫甚至不同服務器，不可避免會帶來分布式事務問題。

跨節點關聯查詢問題

在沒有分庫時，我們可以進行很容易的進行跨表的關聯查詢。但是在分庫后，表被分散到了不同的數據庫，就無法進行關聯查詢了。

這時就需要將關聯查詢拆分成多次查詢，然后將獲得的結果進行拼裝。

跨節點分頁、排序函數

跨節點多庫進行查詢時，limit分頁、order by排序等問題，就變得比較復雜了。需要先在不同的分片節點中將數據進行排序并返回，然后將不同分片返回的結果集進行匯總和再次排序。

這時非常容易出現內存崩潰的問題。

主鍵避重問題

在分庫分表環境中，由于表中數據同時存在不同數據庫中，主鍵值平時使用的自增長將無用武之地，某個分區數據庫生成的ID無法保證全局唯一。因此需要單獨設計全局主鍵，以避免跨庫主鍵重復問題。

公共表處理

實際的應用場景中，參數表、數據字典表等都是數據量較小，變動少，而且屬于高頻聯合查詢的依賴表。這一類表一般就需要在每個數據庫中都保存一份，并且所有對公共表的操作都要分發到所有的分庫去執行。

運維工作量

面對散亂的分庫分表之后的數據，應用開發工程師和數據庫管理員對數據庫的操作都變得非常繁重。對于每一次數據讀寫操作，他們都需要知道要往哪個具體的數據庫的分表去操作，這也是其中重要的挑戰之一。

MySQL單表記錄如果達到500W這個級別，或者單表容量達到2GB，一般就建議進行分庫分表

一般對于用戶數據這一類后期增長比較緩慢的數據，一般可以按照三年左右的業務量來預估使用人數，按照標準預設好分庫分表的方案。

對于業務數據這一類增長快速且穩定的數據，一般則需要按照預估量的兩倍左右預設分庫分表方案。并且由于分庫分表的后期擴容是非常麻煩的，所以在進行分庫分表時，盡量根據情況，多分一些表。最好是計算一下數據增量，永遠不用增加更多的表。

在設計分庫分表方案時，要盡量兼顧業務場景和數據分布。在支持業務場

景的前提下，盡量保證數據能夠分得更均勻。

一旦用到了分庫分表，就會表現為對數據查詢業務的靈活性有一定的影

響，例如如果按userId進行分片，那按age來進行查詢，就必然會增加很多麻煩。如果再要進行排序、分頁、聚合等操作，很容易就扛不住了。這時候，都要盡量在分庫分表的同時，再補充設計一個降級方案，例如將數據轉存一份到ES，ES可以實現更靈活的大數據聚合查詢。

ShardingSphere

MyCat

Dble

Cobar

MySQL 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。