原文：https://www.cnblogs.com/1477717815fuming/p/8006143.html
場景
公司規模已經形成，用戶數據已成為公司的核心命脈，一次老王一不小心把數據庫文件刪除，通過mysqldump備份策略恢復用了兩個小時，在這兩小時中，公司業務中斷，損失100萬，老王做出深刻反省，公司也因此對於數據庫的性能和可靠性提出更高要求。要求對數據庫進行改造，使其承載力進行提升，故障修復時間減少，有沒有能實現的方案呢？
數據庫常遇到的問題
一、性能問題
1、向上拓展 scale up ：針對單台服務器，提高服務器的硬件性能，比如：內存，cpu等，個體本身 容易達到極限
2、向外拓展 scale out ：多台服務器形成集群，共同完成一件事情
二、可用性問題
數據庫高可用技術說明
高可用架構對於互聯網服務基本是標配，無論是應用服務還是數據庫服務都需要做到高可用。雖然互聯網服務號稱7*24小時不間斷服務，但多多少少有一些時候服務不可用，比如某些時候網頁打不開，百度不能搜索或者無法發微博，發微信等。一般而言，衡量高可用做到什么程度可以通過一年內服務不可用時間作為參考，要做到3個9的可用性，一年內只能累計有8個小時不可服務，而如果要做到5個9的可用性，則一年內只能累計5分鍾服務中斷。所以雖說每個公司都說自己的服務是7*24不間斷的，但實際上能做到5個9的屈指可數，甚至根本做不到，國內互聯網巨頭BAT(百度，阿里巴巴，騰訊)都有因為故障導致的停服問題。對於一個系統而言，可能包含很多模塊，比如前端應用，緩存，數據庫，搜索，消息隊列等，每個模塊都需要做到高可用，才能保證整個系統的高可用。對於數據庫服務而言，高可用可能更復雜，對用戶的服務可用，不僅僅是能訪問，還需要有正確性保證，因此，對於實現數據庫高可用，對互聯網公司來說極其重要！
企業級數據庫高可用架構圖
Mysql主從架構技術說明
Mysql內建的復制功能是構建大型，高性能應用程序的基礎。將Mysql的數據分布到多個系統上去，這種分布的機制，是通過將Mysql的某一台主機（Master）的數據復制到其它主機（slaves）上，並重新執行一遍來實現的。復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日志文件，這些日志可以記錄發送到從服務器的更新。當一個從服務器連接主服務器時，它通知主服務器從服務器在日志中讀取的最后一次成功更新的位置。從服務器接收從那時起發生的任何更新，然后封鎖並等待主服務器通知新的更新。
主從復制架構圖
數據庫復制特性
Mysql復制解決的問題
(4) 高可用性和容錯性 High availabilityand failover
Mysql復制如何工作
Mysql的復制功能主要有3個步驟：
(1) 主服務器（master）將改變記錄到二進制日志(binarylog)中（這些記錄叫做二進制日志事件，binary log events）
(2) 從服務器（slave）將主服務器master的binary logevents拷貝到它的中繼日志(relay log)
(3) slave重做中繼日志中的事件，將改變反映它自己的數據。
1、該過程的第一部分就是master記錄二進制日志。在每個事務更新數據完成之前，master在二進制日志記錄這些改變。MySQL將事務串行的寫入二進制日志，在事件寫入二進制日志完成后，master通知存儲引擎提交事務。此后可接收slave的請求
2、下一步就是slave將master的binary log拷貝到它自己的中繼日志。首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，然后開始在主節點上binlog dump process（二進制轉存線程）。Binlog dump process從master的二進制日志中讀取事件，如果已經跟上master，它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日志。
3、 SQL slave thread（SQL從線程）處理該過程的最后一步。SQL線程從中繼日志讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日志通常會位於OS的緩存中，所以中繼日志的開銷很小。
I/O線程：將master數據庫二進制日志拉到slave數據庫上，並將二進制日志寫到中繼日志，寫完之后，他會睡眠並等待master數據庫二進制日志更新，一旦更新，就會寫入slave數據庫的中繼日志中
SQL線程：讀取中繼日志的事件，並在數據庫中執行，寫入到內存中，使slave數據庫的數據與master數據庫中的數據一致
Mysql實現企業級數據庫主從復制架構實戰
注意：slave數據庫只能是可讀的，不能是可寫的，如果改變了slave數據庫的數據，master不能從slave數據庫上同步數據，導致主從數據庫數據不一致。
實戰演練
一、環境准備
centos系統服務器2台、一台用戶做Mysql主服務器，一台用於做Mysql從服務器，都在同一個網段中，配置好yum源、防火牆關閉、各節點時鍾服務同步、各節點之間可以通過主機名互相通信
二、准備步驟：
1、iptables -F && setenforce 清空防火牆策略，關閉selinux
2、拿兩台服務器都使用yum方式安裝Mysql服務，要求版本一致
三、實現步驟:
1、配置master主服務器
對master進行配置，包括打開二進制日志，指定唯一的servr ID。例如，在配置文件加入如下值
server-id=1 #配置server-id，讓主服務器有唯一ID號（讓從服務器知道他的主服務器是誰）
log-bin=mysql-bin #打開Mysql日志，日志格式為二進制
skip-name-resolve#關閉名稱解析，（非必須）
2．創建復制帳號
在Master的數據庫中建立一個備份帳戶：每個slave使用標准的MySQL用戶名和密碼連接master
。進行復制操作的用戶會授予REPLICATION SLAVE權限。（給從服務器授權，讓他能從主服務器拷貝二進制日志）
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@'192.168.10.%' IDENTIFIED BY 'magedu';
3．查看主服務器狀態
在Master的數據庫執行show master status，查看主服務器二進制日志狀態
4、配置slave從服務器
對slave進行配置，打開中繼日志，指定唯一的servr ID，設置只讀權限。在配置文件加入如下值
server-id=2 #配置server-id，讓從服務器有唯一ID號
relay_log = mysql-relay-bin #打開Mysql日志，日志格式為二進制
log_bin = mysql-bin #開啟從服務器二進制日志
log_slave_updates = 1 #使得更新的數據寫進二進制日志中
然后重啟數據庫服務
5．啟動從服務器復制線程
讓slave連接master，並開始重做master二進制日志中的事件。
CHANGE MASTER TO MASTER_HOST='192.168.10.190',
MASTER_LOG_FILE='mysql-bin.000001',
6、查看從服務器狀態
可使用SHOW SLAVE STATUS\G查看從服務器狀態，如下所示，也可用show processlist \G查看前復制狀態：
Slave_IO_Running: Yes #IO線程正常運行
Slave_SQL_Running: Yes #SQL線程正常運行
7.測試
在從服務器上
四、添加新slave服務器
假如master已經運行很久了，想對新安裝的slave進行數據同步，甚至它沒有master的數據。
此時，有幾種方法可以使slave從另一個服務開始，例如，從master拷貝數據，從另一個slave克隆，從最近的備份開始一個slave。為了加快Slave與master同步，可用以下方式先進行數據同步：
實現主從從架構
就是在從服務器也開啟二進制日志，然后從的從I/O線程再將從的二進制日志給拷貝過來寫入到自己的relay log中，然后sql線程再讀取relay log中的事件，在數據庫中執行，寫入到內存中。
Mysql復制過濾器
僅復制有限一個或幾個數據庫相關的數據，而非所有；由復制過濾器進行；
從服務器的SQL THREAD僅重放關注的數據庫或表相關的事件，並將其應用於本地；
企業常見數據庫架構
一、單一master和多slave
在實際應用場景中，MySQL復制90%以上都是一個Master復制到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。因為只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復制的延時一般都很少很少。尤其是自從Slave端的復制方式改成兩個線程處理之后，更是減小了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別高的應用，只需要通過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多台Slave的機器上面，即可通過分散單台數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決數據庫瓶頸。
單一master和多slave架構圖
(1) 不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲引擎)；
(2) 用一個slave作為備用master，只進行復制；#主服務器掛了之后，可在從服務器執行
1> 在備機上執行STOP SLAVE 和RESET MASTER
二、互為主從Master-Master(Master-Master in Active-Active Mode)
Master-Master復制的兩台服務器，既是master，又是另一台服務器的slave。這樣，任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。
即：在兩台服務器上既執行master的操作又執行slave的操作（注意：兩台數據庫都必須是可寫的）
互為主從復制過程
互為主從：兩個節點各自都要開啟binlog和relay log；
對於某些唯一性的字段，可以通過設置自增長ID來實現,自增長ID的數據，代表這個表中存在一條唯一的記錄；而自增長id是肯定不會重復的；
create table userInfo (id int PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL)；
兩邊插入數據看數據增長
insert into userInfo(name) value('xiao'),('da'),('lao');
定義一個節點使用奇數id
auto_increment_increment=2 #表示自增長字段每次遞增的量
auto_increment_offset=1 #表示自增長字段從那個數開始
配置：
2、均啟用binlog和relay log； read only = 0(因為互為主從，所以必須是可寫的)
3、存在自動增長id的表，為了使得id不相沖突，需要定義其自動增長方式；
實驗：數據庫互為主從復制步驟
1.修改mysql配置文件
2．創建復制帳號
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@'192.168.10.%' IDENTIFIED BY 'magedu';
3．啟動從服務器復制線程
讓slave連接master，並開始重做master二進制日志中的事件。
CHANGE MASTER TO MASTER_HOST='192.168.10.190',
MASTER_LOG_FILE='mysql-bin.000001',
4、查看從服務器狀態
可使用SHOW SLAVE STATUS\G查看從服務器狀態，如下所示，也可用show processlist \G查看前復制態：
Slave_IO_Running: Yes #IO線程正常運行
Slave_SQL_Running: Yes #SQL線程正常運行
兩台數據庫服務器都顯示如上結果就ok。
5.創建表，設置ID為自增長,兩邊插入數據看數據增長
create table userinfo (id int PRIMARY KEY AUTO_INCREMENT,name varchar(20) NOT NULL);
insert into userinfo (name) values('ni'),('wo'),('ta');
然后查看表，因為是自增長id，從1開始，步長為2，所以添加的數據id為1,3,5
然后在另一台數據庫服務器插入數據，因為是自增長id，從2開始，步長為2，所以新添加的數據id為6,8,10
排錯：當配置文件中配置中繼日志格式不小心配置錯了，或者讓slave連接master，執行sql語句不小心寫錯了，都有可能導致start slave；報錯，此時可以show slave status\G;會出現一大串信息，里面會提示錯誤。找到錯誤以后，重置slave，reset slave;重新設置，然后再start slave；
注意：mysql的錯誤日志非常重要，可以提供錯誤信息，從而找到錯誤原因。
互為主從容易導致數據不一致，此時我們可以用兩個實例來互為主從
三種復制方式
異步復制（Asynchronous replication）
MySQL默認的復制即是異步的，主庫在執行完客戶端提交的事務后會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能並沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的數據不完整
全同步復制（Fully synchronous replication）
指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步復制的性能必然會收到嚴重的影響。需要有超時時間。
半同步復制（Semisynchronous replication）
介於異步復制和全同步復制之間，主庫在執行完客戶端提交的事務后不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步復制，半同步復制提高了數據的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步復制最好在低延時的網絡中使用。
半同步復制
支持多種插件：/usr/lib64/mysql/plugins/
mysql> INSTALL PLUGIN plugin_name SONAME 'shared_library_name';
主節點：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
+------------------------------------+-------+
+------------------------------------+-------+
| rpl_semi_sync_master_enabled | OFF |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_master_enabled=ON/1;
從節點：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
+---------------------------------+-------+
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
MariaDB [mydb]> STOP SLAVE IO_THREAD;
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_slave_enabled = ON ;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
MariaDB [mydb]> START SLAVE IO_THREAD;
mysql優化：
1.可以用數據緩存，常見的memcache
2.數據庫本身有很多緩存機制，可使用對應的緩存策略
3.對數據來說，竟可能使用索引
4.對請求而言，可以實現讀寫分離，對讀請求負載均衡
5.對大數據庫或者表，可根據業務邏輯進行分庫分表
6.多有的優化，盡可能網內存中存放
分庫分表
分庫：當數據庫的數據非常龐大，可以把數據庫分成幾個數據庫，每個數據庫當一類數據，最后在拼接起來
1.水平拆分：一個表中有10億條記錄，將這10億條記錄分成每10萬條記錄為一個表
