一數據庫安裝：

1 安裝數據庫

數據包下載地址：
鏈接：https://pan.baidu.com/s/16CBO11HBf3Pl4eGEGg5vNw
密碼：3nzg
下載所需的安裝包並進行解壓：

安裝相關數據包

將其發送至客戶端主機

客戶端查看並安裝：

啓動master 數據庫並初始化密碼和修改密碼

其密碼默認在/var/log/mysqld.log中生成

初始化密碼

啓動服務器並安裝是否修改成功

從庫查看密碼位置並進行相關的初始化

查看密碼是否修改成功

二配置mysql數據庫的主從同步

1 主從同步原理：

Replication 線程：
Mysql的 Replication 是一個異步的複製過程（mysql5.1.7以上版本分爲異步複製和半同步兩種模式），從一個 Mysql instace(我們稱之爲 Master)複製到另一個 Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個線程來完成，其中兩個線程(Sql線程和IO線程)在 Slave 端，另外一個線程(IO線程)在 Master 端。
要實現 MySQL 的 Replication ，首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能，否則無法實現。因爲整個複製過程實際上就是Slave從Master端獲取該日誌然後再在自己身上完全順序的執行日誌中所記錄的各種操作。打開 MySQL 的 Binary Log 可以通過在啓動 MySQL Server 的過程中使用 “—log-bin” 參數選項，或者在 my.cnf 配置文件中的 mysqld 參數組([mysqld]標識後的參數部分)增加 “log-bin” 參數項。

2 主從同步的兩個線程及其功能

（1）sql_thread：負責從中繼日誌讀取內容，然後replay到數據庫中；
（2）io_thread：負責連接主服務器，把主服務器的二進制日誌複製到自己的中繼日誌；

3 主從同步的方式

mysql支持單向、異步複製，複製過程中一個服務器充當主服務器，而一個或多個其他服務器充當從服務器。主服務器將更新寫入二進制日誌文件，並維護文件的一個索引以跟蹤日誌循環，這些日誌可以記錄發送到從服務器的更新，當一個從服務器鏈接主服務器時，他通知主服務器從服務器在日誌中讀取的最後一次成功更新的位置，從服務器接受從那時起發生的任何更新，然後封鎖並等待主服務器通知新的更新。

複製優點：
1 主服務器/從服務器設置增加了健壯性，主服務器出現故障時，你可以切換到從服務器作爲備份
2 通過主服務器和從服務器之間切分處理客戶查詢的負荷，可以更好的提高客戶端的響應時間
3 從服務器執行復制，不會影響主服務器的更新和讀寫操作。

4 mysql的AB 複製

mysql數據庫的版本，要麼主庫比從庫版本低，要麼相同。

1 基本server-id及log-bin配置

1 主動端配置：

參數解析：
1 log-bin ：啓動二進制日誌系統
2 server-id: 必須是1-2^32-1 之間的整數
重啓服務器

從庫端配置

重啓服務器

2 權限相關配置：

1 查看主庫相關情況，從庫鏈接主庫便從此開始，並配置相應的用戶和密碼及權限

從庫邊鏈接數據庫操作，並啓用從庫功能

參數詳解：
master_host=主服務器IP
master_user=在主服務器上創建的備份用戶名
master_password=備份用戶密碼
master_log_file=查詢master(主服務器)的狀態得到的File列的值
master_log_pos=Position列的值。其值必須與主庫所對應的值相同
start slave：啓動從服務器複製功能

查看其是否連接成功

3 驗證主從同步：

查看主庫數據庫情況並創建數據庫python

從庫邊查看：

主庫配置數據表並插入數據：

從庫端查看是否成功

主庫刪除數據

從庫查看是否操作成功

相關文件作用：

mysql-bin.index：服務器一旦開啓二進制日誌，會產生一個與二日誌文件同名，但是以.index結尾的文件。它用於跟蹤磁盤上存在哪些二進制日誌文件。MySQL用它來定位二進制日誌文件。
mysqld-relay-bin.index：該文件的功能與mysql-bin.index類似，但是它是針對中繼日誌，而不是二進制日誌。
master.info：保存master的相關信息。不要刪除它，否則，slave重啓後不能連接master。
relay-log.info：包含slave中當前二進制日誌和中繼日誌的信息。
5 配置GTID 的主從同步：

一、GTID的概述：

GTID=UUID+傳輸ID
1、全局事物標識：global transaction identifieds。
2、GTID事物是全局唯一性的，且一個事務對應一個GTID。
3、一個GTID在一個服務器上只執行一次，避免重複執行導致數據混亂或者主從不一致。
4、GTID用來代替classic的複製方法，不在使用binlog+pos開啓複製。而是使用master_auto_postion=1的方式自動匹配GTID斷點進行復制。
5、MySQL-5.6.5開始支持的，MySQL-5.6.10後開始完善。
6、在傳統的slave端，binlog是不用開啓的，但是在GTID中，slave端的binlog是必須開啓的，目的是記錄執行過的GTID（強制）

二、GTID的組成部分：

前面是server_uuid：後面是一個序列號
例如：server_uuid：sequence number
7800a22c-95ae-11e4-983d-080027de205a:10
UUID：每個mysql實例的唯一ID，由於會傳遞到slave，所以也可以理解爲源ID。
Sequence number：在每臺MySQL服務器上都是從1開始自增長的序列，一個數值對應一個事務

三、GTID比傳統複製的優勢：

1、更簡單的實現failover，不用以前那樣在需要找log_file和log_Pos。
2、更簡單的搭建主從複製。
3、比傳統複製更加安全。
4、GTID是連續沒有空洞的，因此主從庫出現數據衝突時，可以用添加空事物的方式進行跳過。

四、GTID的工作原理：

1、master更新數據時，會在事務前產生GTID，一同記錄到binlog日誌中。
2、slave端的i/o 線程將變更的binlog，寫入到本地的relay log中。
3、sql線程從relay log中獲取GTID，然後對比slave端的binlog是否有記錄。
4、如果有記錄，說明該GTID的事務已經執行，slave會忽略。
5、如果沒有記錄，slave就會從relay log中執行該GTID的事務，並記錄到binlog。
6、在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果沒有就用全部掃描。
要點：
1、slave在接受master的binlog時，會校驗master的GTID是否已經執行過（一個服務器只能執行一次）。
2、爲了保證主從數據的一致性，多線程只能同時執行一個GTID。

五配置

1 主庫端配置

重啓服務

2 從庫端配置：

重啓服務

關閉原先的主從同步鏈接並創建基於GTID的主從同步鏈接

查看是否連接成功

3 查看相關的二進制日誌命令

4 測試

主庫插入數據

從庫查看

查看主庫日誌情況，通過後端的數字來確定其同步是否完成，如果和主庫發送的數據相同，則表明從庫同步完成

查看從庫的有關同步字段內容

6 配置線程增加（針對的是IO_thread）

（均在slave端配置）：線程增加配置與將數據由文件存儲轉換爲表存儲的配置
查看原配置線程情況
當配置了多線程之後，原本的單線程將用於處理與服務器master之間的信息操作，而不是用於同步複製。

配置多線程處理和將同步日誌的保存由文件轉義到表的配置，將原本對磁盤的操作優化爲對內存的操作，性能有所提升

參數詳解：
slave_parallel_workers=16
#並行的SQL線程數量，此參數只有設置 1<N的情況下才會才起N個線程進行SQL重做。
#經過測試對比發現，如果主庫的連接線程爲M，只有M < N的情況下，備庫的延遲纔可以完全避免。#否則，延遲一樣的會存在，但是畢竟SQL重做線程從原來的一個，升級到現在的N個，這個延遲在一定的主庫TPS下會很短！
master_info_repository=TABLE
relay_log_info_repository=TABLE
這兩個參數會將master.info和relay.info保存在表中，默認是Myisam引擎，官方建議改爲Innodb引擎，防止表損壞後自行修復。
relay_log_recovery=ON
#當slave從庫宕機後，假如relay-log損壞了，導致一部分中繼日誌沒有處理，則自動放棄所有未執行的relay-log，並且重新從master上獲取日誌，這#樣就保證了relay-log的完整性。默認情況下該功能是關閉的，將relay_log_recovery的值設置爲 1時，可在slave從庫上開啓該功能，建議開啓。

重啓客戶端並查看MySQL庫中增加了記錄同步日誌的GTID 的表

查看此表情況

查看線程數是否增加，增加15個：

7 半同步配置：

1 mysql 5.7 與 5.6 半同步比較

mysql 5.6 是當master提交事務之前，會向slave端發送binlog並提交事務，等到slave端返回成功後再返回給客戶端，

mysql 5.7 是在master提交事務之前，會向slave端發送binlog 信息，並等待客戶端返回成功後提交事務，並返回給客戶端。
mysql5.7 的可靠性更高

2 主庫端加載master模塊：

3 從庫端配置：

主庫端查看配置情況

其中rpl_semi_sync_master_enabled是控制Master是否開啓半同步，開啓或不開啓,將其設
置爲ON或OFF(1or0).
rpl_semi_sync_master_timeout是控制Master等待多長時間被告知Slave已收到，也就是所
謂的超時時間。
rpl_semi_sync_slave_enabled是控制Slave是否開啓半同步，開啓或不開啓，將其設置爲ON
或OFF(1or0)。
其master處於開啓狀態。發現了slave

監控半同步複製的狀態變量（幾個常用的）：
Rpl_semi_sync_master_clients：查看有多少個開啓半同步複製的插件的Slave
Rpl_semi_sync_master_status：查看在Master上半同步複製是否正在運行，其值爲ON時，
說明Master已啓用半同步且已被告知有Slave收到；其值爲OFF時，說明Master沒啓用半同步
或是沒被告知，由於timeout等原因。
Rpl_semi_sync_master_no_tx：查看有多少事務沒有用半同步複製的機制進行復制。
Rpl_semi_sync_master_yes_tx：查看有多少事務是通過半同步複製機制成功複製。
Rpl_semi_sync_slave_status：查看Slave上半同步複製是否正常運行，其值爲ON時，說明
Slave正通過半同步複製且Slave I/O正在運行；爲OFF時，反之。
重啓io_thread使用相同步驟配置從節點，完成後需要重啓io_thread，不重啓當執行時會超
時，超時後則自動降爲異步：

8 數據庫的級聯配置：

同步方式，使用半同步的方式進行
server1---->server2(是server1 的從，也是server3的主)------>server3
架構圖：

server1 端配置：

用於使得加載模塊的永久性

2 server2

需要加載master模塊並激活，並且需要日誌log-bin文件，因爲其是主庫

3 server3 配置

1 加載slave 模塊。

2 建立數據庫並將server2的相關配置導入

3 重啓服務

4 將GTID等相關參數寫入配置文件：

5 重啓服務加載模塊

6 進行連接server2 數據庫：

4 查看配置：

server2

server3

5 測試。

此時必須在server1 端進行測試：

8 mysql數據庫的讀寫分離：

環境server1 爲server2的主服務器.server3 爲調度器，用於向客戶端提供一個API接口，用於調用mysql數據庫

1 基礎準備：

關閉server3的數據庫並設置爲開機不啓動：

server1端配置權限，用於mysql數據庫的遠程登錄：

2 安裝第三方軟件

解壓配置並將其名稱改爲mysql-proxy

啓動服務：

3 創建配置文件和日誌文件目錄：

創建並配置配置文件：

參數詳解：
--proxy-address=host:port ———— 代理服務監聽的地址和端口
--admin-address=host:port ———— 管理模塊監聽的地址和端口
--proxy-backend-addresses=host:port ———— 後端mysql服務器的地址和端口（主服務器）
--proxy-read-only-backend-addresses=host:port ———— 後端只讀mysql服務器的地址和端口（從服務器）
--proxy-lua-script=file ———— 完成mysql代理功能的Lua腳本
--daemon ———— 以守護進程模式啓動mysql-proxy
--defaults-file=/path/to/conf_file_name ———— 默認使用的配置文件路徑
--log-file=/path/to/log_file_name ———— 日誌文件名稱
--log-level=level ———— 日誌級別
--log-use-syslog ———— 基於syslog記錄日誌
--user=user_name ———— 運行mysql-proxy進程的用戶
修改其讀寫分離規則：

其表示爲至少鏈接1次和至多鏈接2 次就切換到從庫。
授其執行權限權：

安裝查看鏈接的軟件：lsof

4 啓動並查看服務是否成功

5 遠程鏈接測試：

9 mysql的組複製：

1 組複製限制：

存儲引擎必須爲Innodb
每個表必須提供主鍵
只支持ipv4，網絡需求較高
一個組最多只能有9臺服務器
不支持 Replication event checksums，
不支持 Savepoints
多主模式不支持SERIALIZABLE事務隔離級別
多主模式不能完全支持級聯外鍵約束
多主模式不支持在不同節點上對同一個數據庫對象併發執行DDL(在不同節點上對同一行併發進行RW事務，後發起的事務會失敗)

2 複製結構圖

使用場景：
1 彈性複製
2 高可用分片
3 代替主從複製
4 自動系統

3 文件配置：my.cnf

server 1 端配置

參數詳解：
1 transaction_write_set_extraction=XXHASH64
server 必須爲每個事物收集寫集合，並使用XXHASH64 哈希算法將其編碼爲散列
2 loose-group_replication_group_name
告知插件，正在加入或創建的組要命名爲後端的內容
3 loose-group_relication_start_on_boot=off
指示插件在server啓動時不自動啓動組複製
4 loose-group——replication_local_address=“”
告知插件本節點使用的IP地址
5 loose-group_replication_bootstrap_group=off
告知插件，當下面這些server需要加入組時，應該鏈接到這些主機和端口上訪問他們。此選項不是列出組中的所有成員，而是當次server需要加入組時需要訪問的server列表
6 loose-group_replication_single_primary_mode=FALSE
本次搭建的是mutil_mode
server 2 端配置

server 3 端配置

4 重啓服務使其加載配置

5 mysql內部配置

server 1 端配置

1 關閉二進制日誌。使其不被記錄到日誌中
set sql_log_bin=0;
2 創建複製用戶與授權
grant replication slave on . to admin@'%' identified by 'ADMIN@root1';
3 刷新授權
flush privileges;
4 開啓二進制日誌記錄功能
set sql_log_bin=1;
5 設置組相關信息
change master to master_user='admin',master_password='ADMIN@root1' for channel 'group_replication_recovery';
6 安裝GR 插件
install plugin group_replication soname 'group_replication.so';
7 開啓master啓動後組複製自動進行
set global group_replication_bootstrap_group=ON;
8 設置發現方式
set global group_replication_ip_whitelist="172.25.254.0/24";
Query OK, 0 rows affected (0.00 sec)
9 啓動組：
start group_replication;
10 關閉master啓動後組複製自動進行
set global group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
11 查看是否成功
select * from performance_schema.replication_group_members;
server 2 端配置：

兼容加入組
set global group_replication_allow_local_disjoint_gtids_join=ON;
server 3 端配置：

6 測試

其創建的數據表應該有主鍵，不能重複。

10 mysql MHA 配置：

server1 爲server2 和server3 的master 但server2 可以作爲server1 的slave 也可以在server1down之後作爲server3的主設備，server3 不具備做主master的權利。
server3 上有調度器

1 介紹：

MHA，即MasterHigh Availability Manager and Toolsfor MySQL，是日本的一位MySQL專家
採用Perl語言編寫的一個腳本管理工具，
該工具僅適用於MySQLReplication 環境，目的在於維持Master主庫的高可用性。
MHA(Master High Availability)是自動的master故障轉移和Slave提升的軟件包.
它是基於標準的MySQL複製(異步/半同步).
2 MHA組成部分：
MHA由兩部分組成：
MHA Manager(管理節點)
MHA Node(數據節點)
3 MHA部署解讀：
MHA Manager可以單獨部署在一臺獨立機器上管理多個master-slave集羣,也可以部署在一
臺slave上.
MHA Manager探測集羣的node節點,當發現master出現故障的時候,它可以自動將具有最新數
據的slave提升爲新的master,然後將所有其它的slave導向新的master上.整個故障轉移過程
對應用程序是透明的。
MHA node運行在每臺MySQL服務器上(master/slave/manager),它通過監控具備解析和
清理logs功能的腳本來加快故障轉移的。
4 MHA優缺點介紹：
優點：

故障切換時，可以自行判斷哪個從庫與主庫的數據最接近，就切換到上面，可以減少數
據的丟失，保證數據的一致性
支持 binlog server，可提高 binlog 傳送效率，進一步減少數據丟失風險。
可以配置 mysql 5.7 的增強半同步，來保證數據的時時同步
缺點：
自動切換的腳本太簡單了，而且比較老化，建議後期逐漸完善。
搭建 MHA 架構，需要開啓 linux 系統互信協議，所以對於系統安全性來說，是個不小
的考驗。
5 原理介紹：
MHA的目的在於維持MySQL Replication中Master庫的高可用性，其最大特點是可以修復多個
Slave之間的差異日誌，最終使所有Slave保持數據一致，然後從中選擇一個充當新的Master，並將其它Slave指向它。當master出現故障時，可以通過對比slave之間I/O thread 讀取主庫binlog的position號，選取最接近的slave做爲備選主庫（備胎）。其它的從庫可以通過與備選主庫對比生成差異的中繼日誌。
在備選主庫上應用從原來master保存的binlog，同時將備選主庫提升master。最後在其它slave上應用相應的差異中繼日誌並開始從新的master開始複製。
mysql高可用.txt
6 MHA工具包功能介紹：
Manager工具:
#masterha_check_ssh : 檢查MHA的SSH配置。
#masterha_check_repl : 檢查MySQL複製。
#masterha_manager : 啓動MHA。
#masterha_check_status : 檢測當前MHA運行狀態。
#masterha_master_monitor : 監測master是否宕機。
#masterha_master_switch : 控制故障轉移(自動或手動)。
#masterha_conf_host : 添加或刪除配置的server信息。
7 . Node工具：
#save_binary_logs : 保存和複製master的二進制日誌。
#apply_diff_relay_logs : 識別差異的中繼日誌事件並應用於其它slave。
#filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用這個工具)。
#purge_relay_logs : 清除中繼日誌(不會阻塞SQL線程)。
1 主從同步的搭建

server1上配置文件配置：

server2 上配置：

server3上配置：

server1和server2上開啓半同步主從模塊

server3上開啓從同步模塊

重啓server1server2server3 加載配置文件

配置主從同步：
server2 端

server3 端

2 MHA軟件安裝

必須保證ssh均能實現無密碼登錄

1 安裝節點軟件：

2 安裝控制節點軟件：

server1 端進行授權，使得MHA能夠操作mysql。

參數詳解：
1 hostname：目標實例的主機名或者IP地址，這個參數是強制的，只能配置在app配置文件的[server_xxx]段落標記下
2 port：目標實例的端口，默認是3306，MHA使用mysql server的IP和port連接
3 ssh_user ：ssh方式鏈接其他主機使用的用戶名
4 candidate_master：從不同的從庫服務器中，提升一個可靠的機器爲新主庫，可以通過在配置文件中對應的從庫服務器的配置段下添加candidate_master=1來提升這個從庫被提升爲新主庫的優先級
5 no_master：通過在目標服務器的配置段落設置no_master=1，它永遠也不會變爲新主庫，
6 repl_user：在所有slave上執行change master的複製用戶名，這個用戶最好是在主庫上擁有replication slave權限
7 repl_password：repl_user參數指定的用戶的密碼，默認情況下，是當前複製帳號的密碼，如果你運行了online master switch腳本且使用了–orig_master_is_new_slave做在線切換，當前主庫作爲了從庫加入新主庫，此時，如果你沒有設置repl_password來指定複製帳號的密碼，當前主庫作爲從庫加入新主庫的時候會在change master的時候失敗，因爲默認情況下這個密碼是空的，MHA做切換的時候，其他所有作爲從庫加入新主庫時，都需要使用這個密碼
8 remote_workdir：每一個MHA node（指的是mysql server節點）生成日誌文件的工作路徑，這個路徑是絕對路徑，如果該路徑目錄不存在，則會自動創建，如果沒有權限訪問這個路徑，那麼MHA將終止後續過程，另外，你需要關心一下這個路徑下的文件系統是否有足夠的磁盤空間，默認值是/var/tmp
9 master_binlog_dir：在master上生成binlog的絕對路徑，這個參數用在master掛了，但是ssh還可達的時候，從主庫的這個路徑下讀取和複製必須的binlog events，這個參數是必須的，因爲master的mysqld掛掉之後，沒有辦法自動識別master的binlog存放目錄。默認情況下，master_binlog_dir的值是/var/lib/mysql,/var/log/mysql，/var/lib/mysql目錄是大多數mysql分支默認的binlog輸出目錄，而 /var/log/mysql是ubuntu包的默認binlog輸出目錄，這個參數可以設置多個值，用逗號隔開
10 manager_workdir：mha manager生成的相關狀態文件的絕對路徑，如果沒有設置，則默認使用/var/tmp
11 manager_log：mha manager生成的日誌據對路徑，如果沒有設置，mha manager將打印在標準輸出，標準錯誤輸出上，如：當mha manager執行故障轉移的時候，這些信息就會打印
12 ping_interval：這個參數表示mha manager多久ping（執行select ping sql語句）一次master，連續三個丟失ping連接，mha master就判定mater死了，因此，通過4次ping間隔的最大時間的機制來發現故障，默認是3，表示間隔是3秒
13 master_ip_failover_script：通常在MHA環境下，通常需要分配一個VIP供master用於對外提供讀寫服務，如果master掛了，HA軟件指引備用服務器接管VIP，另外一個通用的方法，是在數據庫中創建一個全局的應用程序名稱與讀寫IP地址之間的全局類目映射（ {app1_master1, 192.168.0.1}, {app_master2, 192.168.0.2}, …）來代替VIP地址的使用，在這種情況下，如果你的master掛了，你需要更新這個數據庫中的全局類目映射。第二種方法這裏個人覺得跟智能DNS解析類似。
14 master_ip_online_change_script：這是一個與master_ip_failover_script 參數很接近的參數，但是這個參數不使用故障轉移命令，而是master的在線change命令
15 shutdown_script：你可能想要強制關閉master節點來避免master節點重新啓動服務，這對於避免腦裂來說是很重要的，

16 report_script：在故障轉移完成或者說因爲錯誤而終止的時候，你可能希望發送一個報告出來，這就是使用report_script 參數的目的
17 init_conf_load_script：這個腳本在你不想在配置文件中設置純文本的信息的時候使用