mysql主從復制筆記

1.故障級別

S1 最嚴重的，影響30%的交易額持續15分鐘以上，或者影響30%的用戶正常訪問，持續15分鐘以上
S2 比較嚴重，影響15%的交易額15分鐘以上
S3 嚴重故障，影響5%的交易額15分鐘左右
S4 故障，影響1%的交易額

2.性能問題

Scale up：單臺服務器的硬件升級來提高性能，容易達到極限
Scale out：增加服務器的數量，利用負載均衡，進行統一管理

3.mysql主從復制過程架構圖

第一步：mysql將事務串行的寫入二進制日志
第二步：slave通過I/O線程將master的二進制日志（binary log events）拷貝到自己的中繼日志。
第三步：slave的SQL（從線程）從中繼日志中讀取事件，并重放其中的事件從而更新slave的數據，使其與master中的數據一致。

4.數據庫主從架構復制（關selinux和iptables）

環境準備：一臺做mysql主服務器，一臺做mysql從服務器，時鐘最好同步。
1）配置主master服務器
2）配置master主服務器
首先配置/etc/my.cnf文件
server-id=1 # 配置一個ID號，從而與其他的服務器區分開來
log-bin=mysql-bin #打開mysql日志，格式為二進制
接下來創建slave的賬號
MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO slave@'172.17.253.127' IDENTIFIED BY '123456';
查看主服務器狀態
Show master status；
3）配置slave服務器
首先配置/etc/my.cnf文件
server-id=2 #配置ID號，從而與其他服務器區分開來
relay-log=mysql-relay-log #打開mysql日志，格式為二進制
read-only=1 #設置只讀權限
log-bin=mysql-bin #開一從服務器二進制日志
log-slave-updates=1 #使更新的數據寫進二進制日志中
接下來啟動從服務器復制線程（與master需要一個網段內）
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.17.253.191', MASTER_USER='slave', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=419;
啟動復制線程
Start slave;
查看服務器狀態，有這兩項則啟動成功
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
4）在master上創建庫，slave上可以查看到，結束！

5.mysql復制過濾器

概念：并不復制所有數據，而僅復制一個或幾個數據庫相關的數據，有兩種實現思路。
一是在主服務器上設置，僅向二進制文件中記錄有關特定數據庫相關的寫操作
Binlog_do_db= 僅僅做某個操作
Binlog_ignore_db= 除了設定的操作，其他的都做
二是在從服務器的設置，在SQL線程僅放關注的數據庫或表相關的事件
Replicate_do_db= 僅讀指定的數據
Replicate_ignore_db= 除了指定的數據，都讀入

6.企業常見數據庫架構

1）單一master和多個slave
實際中百分之90都是這樣的架構，因為大部分情況下都是讀訪問比寫訪問要多的多，在這種情況下，對于數據實時性要求不是很高的話，單純增加slave的數量，比較廉價而且效果很好。

2）兩個master互為主從
Master-master復制的兩臺服務器，既是master，又是另一臺的salve，這樣，任何一方所做的變更，都會通過復制應用到另一方的數據庫中。
# 172.17.253.191上進行如下操作
My.cnf配置文件中加入
auto_increment_offset=1
auto_increment_increment=2 ##使用奇數ID
進行數據庫配置
MariaDB [LN]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO slave@'172.17.253.127' IDENTIFIED BY '123456';
MariaDB [LN]> CHANGE MASTER TO MASTER_HOST='172.17.253.127', MASTER_USER='slave', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=245;
Start slave；
Show status slave\G；IO和SQL為yes即可
172.17.253.127上進行如下操作
auto_increment_offset=2
auto_increment_increment=2##使用偶數ID
進行數據庫配置
MariaDB [LN]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO slave@'172.17.253.191' IDENTIFIED BY '123456';
MariaDB [LN]> CHANGE MASTER TO MASTER_HOST='172.17.253.191', MASTER_USER='slave', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=245;
Start slave；
Show status slave\G；IO和SQL為yes即可
測驗：
在191上創建表，并設置為自增長ID，檢驗效果

使用LN數據庫

創建自增長ID表

在127上插入數據

查看表，成功

7.自增長ID，主鍵，外鍵，索引

自增長ID：對于某些唯一性的字段，例如一個班的學生的學號，可以通過設置自增長ID來實現，自增長ID的數據，代表這個表中存在一條唯一的記錄，而且自增長ID是肯定不會重復的。
主鍵：關系型數據庫的一條記錄有若干個屬性，若其中某一個屬性組（注意是組）能唯一標識一條記錄，該屬性組就可以成為一個主鍵，如學生表（學號，姓名，性別，班級）中，學號就是一個主鍵
外鍵：例如成績表（學號，課程號，成績），學號和課程號合稱為主鍵，因為單單一個學號或者課程號并不能標識一個學生的成績，而在學生表（學號，姓名，性別，班級）中，學號是主鍵，此時成績表中的學號就是學生表中的外鍵。
外鍵主要用來連表查詢，即通過學號查詢了相關信息后，再把學號映射到成績表中，和課程號結合，可以查看成績。
索引：快速搜索的關鍵，沒有索引的話，查詢的時候會全庫查詢，比較慢

8.復制策略:異步，全同步，半同步

異步：這是默認的復制策略，master在執行完客戶端的請求后，會立即將結果返給客戶端，并不關心slave是否已經接受并處理，這樣就會帶來一個問題，當master宕機時，master的數據可能還沒有全部傳輸到slave上，如果此時，強行將slave提升為master，就會造成數據不完整。
全同步：當master執行完一個客戶端的請求后，會等待所有的slave執行完數據復制后才將事務返還給客戶端，然而這樣性能會受到嚴重的影響。
半同步：介于上述兩者之間，當master執行完客戶端的請求后，會等待至少一臺slave完成數據復制才會將事務返還給客戶端，這樣提高了數據的安全性，但是也造成了一定程度的延遲，所以，半同步最好在延遲低的網絡中使用。

9.開啟半同步復制

主上
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled=ON;
SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';

| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
從上
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
MariaDB [mydb]> STOP SLAVE IO_THREAD;
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_slave_enabled = ON ;
MariaDB [mydb]> START SLAVE ;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
查看是否生效
Tail -200 /var/log/mariadb/mariadb.log，有以下記錄則生效

10.MHA

1）
是什么：（Master HA），即主高可用，它為mysql主從復制架構提供了自動成為主的功能，當master宕機的時候，mha會監控到故障的節點，并且提升擁有最新數 據的slave節點成為新的master，并且還會自動通過其他節點獲得額外的信息來避免一致性方面的問題，mha還提供了master在線切換的功能，即按需要切換master/slave節點。
2）MHA工作原理總結
?從宕機崩潰的master保存二進制日志事件
?識別含有最新更新的slave
?應用差異的中繼日志到其他的slave
?應用從master保存的二進制日志事件
?提升一個slave為新的master
?使用其他的slave連接新的master進行復制

11.Mysql高可用架構之MHA

1）環境準備
一臺做manager節點，一臺做master節點，一臺以上的slave節點。
2）在各節點的/etc/hosts文件配置內容中添加：
172.17.253.25 node1.magedu.com node1
172.17.253.127 node2.magedu.com node2
172.17.253.191node3.magedu.com node3
這樣做的目的是在今后的工作中，能夠通過域名對應的編號更快速的找到故障的機器
3）matse節點配置
[mysqld]
Server-id=1
Log-bin=master-log
Relay-log=relay-log
Skip_name_resolve=ON
slave節點配置
[mysqld]
server-id = 12
relay-log = relay-log
log-bin = master-log
read_only = ON
relay_log_purge = 0
skip_name_resolve = YES
4)做好主從復制，確保slave和master工作正常，在slave上的IO和SQL線程正常鏈接（上面有）
5）準備基于ssh互相通信環境
ssh-keygen -t rsa #生成密鑰
ssh-copy-id root@172.17.253.191 #將公鑰傳給需要面密碼登陸的機器，輸入yes和密碼后，就成功了。
6)在master上安裝
mha4mysql-manager-0.56-0.el6.noarch.rpm 和mha4mysql-node-0.56-0.el6.norch.rpm.
在master和所有slave節點上安裝 mha4mysql-node-0.56-0.el6.norch.rpm.
7）定義mha的配置文件

8）在manager上檢測各個節點之間的ssh通信是否OK

OK后檢測復制集群的鏈接配置是否正常

如果有報錯，就看報錯提示的是什么，可能是權限問題，可能是防火墻問題，也可能是主從復制沒有實現等等
9）啟動mha

檢測開啟狀態

10）模擬master故障，關掉master上的mariadb服務，檢測manager.log日志查看是否master自動轉移到了slave上面。
11）轉移成功后，再將master和slave配置好，然后啟動mha服務就OK了