基於MySQL的架構優化

mysql的複製：

實現在不同服務器上的分佈：
    利用二進制日誌增量進行；
    不需要太多的帶寬，但是使用基於行的複製在進行大批量的更改時，會對帶寬帶來一定的壓力，特別是跨IDC環境下進行的複製；  
    應該分批進行
實現數據讀取的負載均衡，需要其他組件配合使用
增加數據的安全性
實現數據庫高可用和故障切換
實現數據庫在線升級

mysql的二進制日誌：記錄了所有對MySQL數據庫的數據增刪查改和對錶和數據庫的修改

binlog命令行的工具進行查看

二進制日誌格式：

基於段的日誌格式： binlog_format=STATEMENT

基於行的日誌格式： binlog_format=ROW
    binlog_row_image=[FULL|MINIMAL|NOBLOB]

mysqlbinlog -vv 日誌文件名稱；

混合日誌格式：binlog_format=MIXED
    根據sql語句由系統決定使用基於段還是基於行的日誌格式；
    數據量的大小由所執行的sql語句決定

建議使用binlog_format=MIXED 或者 binlog_format=ROW並設置binlog_row_image=MINIMAL

基於SQL語句的複製(SBR)

優點：
生成的日誌量少，節約網絡傳輸IO
並不強制要求主從數據庫的表定義完全相同
相比於基於行的複製方式更爲靈活

缺點：
對於非確定性事件，無法保證主從數據的一致性
對於存儲過程，觸發器，自定義函數進行的修改也可以造成數據不一致
相對於基於行的複製方式在從上執行時需要更多的行鎖

基於行的複製（PBR）

優點：

可以應用於任何SQL的複製包括非確定確定函數，存儲過程等；
可以減少數據庫鎖的使用

缺點：

要求主從數據庫的表的結構相同，負責可能會中斷複製；
無法在從服務器上單獨執行觸發器

mysql複製的工作方式

主服務器將變更寫入到二進制文件中
從服務器讀取主服務器的二進制日誌變更寫入到relay_log中
在從服務器上重放rely_log中的日誌

基於日誌點的複製配置的步驟：

1.在主DB服務器上建立複製賬號

    create user 'repl' @ 'IP段' identified by 'password';
    grant replication slave on *.* to 'repl' @ 'IP段';//授權

2.配置主庫服務器

    bin_log=mysql-bin
    server_id = 100

3.配置數據庫從服務器

    bin_log = mysql-bin
    server_id = 101
    relay_log = mysql-relay-bin
    log_slave_update = on[可選]
    read_only = on[可選]

4.初始化從服務器數據

    mysqldump --master-data=2 -single-transaction
    xtrabackup --slave-info[對innodb性能不進行鎖表]

5.啓動複製鏈路

    change master to master_host = '主服務器的ip地址' ，
        master_user = 'repl'，
        master_password = 'password'，
        master_log_file = 'mysql_log_file_name'，
        master_log_pos = 4; 
實際的配置：

    1.配置主庫：
        create user repl@'192.168.25.%' identified by '123456';
        grant replication slave on *.* to repl@'192.168.25.%';

    2.修改主從配置文件

    3.主數據庫備份：mysqldump --single-transcation --master-data --triggers --         routines --all-databases >> all.sql

    4.將主庫的生成的備份文件傳遞到從服務器上：scp all.sql [email protected]:/root

    5.在從服務器上執行該sql文件： mysql -uroot -p < all.sql

    6.在從服務器上配置數據鏈路：change master to master_host='192.168.25.33',
                            master_user='repl',
                            master_password='123456',
                            master_log_file='mysql-bin.0000003',
                            mater_log_pos=1829; 

    7.在從服務器上啓動複製鏈路：start slave;
基於日誌點的複製優點：
    是mysql最早的複製技術，bug較少
    對於sql查詢沒有任何限制
    故障處理比較容易
基於日誌點的複製缺點：
    故障轉移時重新獲取新主的日誌點的信息比較困難

基於GTID的複製配置的步驟：

    1.在主DB服務器上簡歷複製賬號

        create user 'repl' @ 'IP段' identified by 'password';
        grant replication slave on *.* to 'repl' @ 'IP段';//授權

    2.配置主庫服務器

        bin_log=mysql-bin
        server_id = 100
        gtid_mode = on

        enforce-gtid-constistency
            不支持以下操作：create table ... select
                          在事務中使用create temporary建立臨時表
                          使用關聯更新事務表和非事務表
        log-slave-updates = on[5.7版本之前加]

    3.配置數據庫從服務器

        server_id = 101
        relay_log = mysql-relay-bin
        gtid_mode=on
        enforce-gtid-constistency
        read_only = on[可選]
        master_info_repository=table
        relay_log_info_repository=table

    4.初始化從服務器數據

        mysqldump --master-data=2 -single-transaction
        xtrabackup --slave-info

    5.啓動複製鏈路

        change master to master_host = '主服務器的ip地址' ，
            master_user = 'repl'，
            master_password = 'password'，
            master_auto_position=1;

基於gtid的複製的優點：
    可以很方便的進行故障的轉移
    從庫不會丟失主庫上的任何修改

基於gtid的複製的缺點：
    故障處理比較複雜
    對執行的SQL有一定的限制

如何選擇複製模式
1. 所使用的MySQL版本
2. 複製的架構及主從切換的方式
3. 所使用的高可用管理組件
4. 對應用的支持程度
MySQL複製拓撲結構

MySQL5.7之前，一個從庫只能有一個主庫

MySQL5.7之後支持一從多主架構

常見的拓撲的設計及設計的注意事項:

一主多從的複製拓撲

優點：配置簡單
     可以用多個從庫分擔讀負載

用途：爲不同業務使用不同的從庫
     將一臺從庫放到遠程的IDC中，用作災備恢復
     分擔主庫的讀負載

主-主複製拓撲

缺點：
    產生數據衝突而造成複製鏈路的中斷
    耗費大量的時間
    造成數據的丟失

主主模式下的主主複製的配置的注意事項：
    兩個主中所操作的表最好能夠分開
    使用下面兩個參數自增ID的生成
        auto_increment_increment = 2
        auto_increment_offset = 1|2

主-備複製的拓撲

特點：
    只有一臺主服務器對外提供服務
    一臺服務器處於只讀狀態並且只作爲熱備使用
    在對外提供的主庫出現故障或是計劃性的維護時纔會進行切換,使原來的備庫成爲主庫，而原來的主庫會成爲新的備庫並處理只讀或下線狀態，待維護完成後重新上線

主備模式下的主主複製的配置的注意事項：
    確保兩臺服務器上的初始化的初始數據相同
    確保兩臺服務器上已經啓動binlog並且有不同的server_id
    在兩臺服務器上啓用log_slave_updates參數
    在初始的備庫上啓用read_only

- 帶從服務器的主主複製的拓撲

級聯複製的拓撲

將一個主服務器配置一個從服務器通過從服務器來分發進行復制

mysql級聯複製

MySQL複製性能的優化

影響主從延遲的因素
1. 主庫寫入二進制日誌的時間 –> 控制主庫中執行事務的大小，分隔大事務
2. 二進制日誌傳輸時間 –> 使用mixed日誌格式，設置set binlog_row_image=minimal;
3. 默認情況下只有一個SQL線程，主上併發修改在從上變成了串行化 –> 使用多線程複製
如何在MySQL5.7中配置數據庫的多線程的複製[MYSQL5.6中引入多線程的複製,在MySQL5.7中可以按照邏輯時鐘的方式來分配SQL線程]：

1.stop slave //停止主從複製
2.set global slave_parallel_type=’logical_clock’; //設置分配線程的方式
3.set global slave_parallel_workers=4; //設置4個複製線程
4.start slave;

MySQL複製常見的問題

由於數據的損壞或者丟失所引起的主從複製錯誤

主庫或者從庫的意外宕機所引起的錯誤 –> 跳過二進制日誌的事件/注入空事務的方式先恢復中斷的複製鏈路，再使用其他的方法來對比主從服務器上的數據

主庫上的二進制日誌損壞 –> 通過change master命令來重新指定

備庫上的中繼日誌損壞

在從庫上進行數據修改造成的主從複製的錯誤

不唯一的server_id或者server_uuid(server_uuid是記錄在數據目錄中的auto.cnf文件中，一旦存在mysql不會生成server_uuid)

max_allow_packet設置引起的主從複製錯誤

MySQL主從複製無法解決的問題

無法分擔主數據庫的寫負載
無法自動進行故障轉移及主從切換
不提供讀寫分離的功能

利用主從複製搭建高可用的架構

高可用性指的是通過儘量縮短因日常維護操作（計劃）和突發的系統崩潰（非計劃）所導致的體積世家你，以提高系統和應用的可用性。
實現高可用

》避免導致系統不可用的因素，減少系統不可用的時間[服務器磁盤空間耗盡、性能低下的SQL、表結構和索引沒有優化、主從數據不一致、人爲的操作失誤]

》建立完善的監控及報警系統

》對備份數據進行恢復測試

》正確配置數據庫環境

》對不需要的數據進行歸檔和清理

》增加系統冗餘，保證發生系統不可用時可以儘快的恢復[避免存在單點故障、主從切換及故障轉移]
```
利用sun共享存儲或者drdb磁盤複製解決MySQL單點故障
利用多寫集羣或者NDB集羣來解決MySQL單點的故障
利用MySQL的複製來解決MySQL的單點登錄的問題
```

MySQL數據庫的MMM架構

在主庫出現宕機時進行故障轉移並自動配置其他從對新主的複製

提供了主，寫虛擬ip，在主從服務器出現問題時可以自動遷移虛擬ip

MMM部署所需資源

名稱資源	數量	說明
主DB服務器	2	用於主備模式的主主複製配置
從DB服務器	0-N	可以配置0臺或多臺從服務器，但建議不要太多
監控服務器	1	用於監控mysql監控集羣
IP地址	2*(n+1)	n爲MySQL服務器的數量
監控用戶	1	用於監控數據庫狀態的MySQL用戶(replication client)
代理用戶	1	用於MMM代理的MySQL用戶(super,replication client,process)
複製用戶	1	用於配置MySQL複製的MySQL用戶(replication slave)

MMM架構的部署步驟

配置主主複製及主從同步集羣
安裝主從節點所需要的支持包（per依賴包）
安裝及配置MMM工具集
運行MMM監控
測試

MySQL高可用架構之MMM架構的詳細配置

MMM集羣的優缺點：

》MMM集羣的優點：

使用Perl腳本語言開發及完全開源
提供了讀寫VIP(虛擬IP),使服務器角色的變更對前端應用透明
MMM提供了從服務器的延遲監控
MMM提供了主數據庫故障轉移後從服務器對新主的重新同步的功能
很容易對發生故障的主數據庫重新上線
MMM提供了從服務器的延遲監控

》MMM集羣的缺點：

發佈時間比較早不支持MySQL新的複製功能
沒有讀負載均衡的功能
在進行主從切換時，容易造成數據丟失
MMM監控服務存在單點故障

MySQL數據庫的MHA架構

監控主數據庫服務器是否可用

當主DB不可用時，從多個從服務器中選舉出新的主數據庫服務器

提供了主從切換和故障轉移功能（MHA可以半同步功能結合起來使用）

MHA如何進行主從切換

當主數據庫出現故障時，嘗試從出現故障的主數據庫保存二進制日誌

從多個備選從服務器中選舉出新的備選主服務器

在備選主服務器和其它從服務器之間同步差異二進制數據

應用從原主DB服務器上保存的二進制日誌

提升備選主DB服務器爲新的主DB服務器

遷移集羣中的其它從DB做爲新的主DB的從服務器
MHA支持GTID的複製和日誌點的複製
MMM不支持GTID的複製

MHA架構的部署步驟

配置集羣內所有服務器的SSH的免認證登錄

ssh -keygen

ssh-copy-id -i /root/.ssh/id_rsa '-p 22 [email protected]

ssh-copy-id -i /root/.ssh/id_rsa '-p 22 [email protected]

ssh-copy-id -i /root/.ssh/id_rsa '-p 22 [email protected]
安裝MHA-node軟件包和MHA-manager軟件包
安裝MHA的支持包

監控節點：yum -y install perl-Config-Tiny.noarch perl-Time-HiRes.X86_64 perl-Parallel-ForkManager perl-Log-Dispatch-Perl.noarch per-DB-MySQL ncftp

數據節點：yum -y install perl -DBD-MySQL ncftp perl-DBI.X86
建立主從複製集羣
配置MHA管理節點
使用master_check_ssh和masterha_check_repl對配置進行檢驗
啓動並測試MHA服務

MySQL高可用架構之MHA介紹及配置

MHA集羣的優缺點：

》MHA集羣的優點：

使用Perl腳本語言開發及完全開源
可以支持就GTID的複製模式
MHA在進行故障轉移時不容易產生數據丟失
同一個監控節點可以監控多個集羣

》MMM集羣的缺點：

需要編寫腳本或利用第三方工具（keepalive等等）來實現VIP的配置
MHA啓動後只會對主數據庫進行監控
需要基於SSH免認證配置，存在一定的安全隱患
沒有提供從服務器的讀負載均衡的功能

數據庫的讀寫分離（如何在複製集羣的不同角色上，去執行不同的SQL語句）

程序實現的讀寫分離

優點：由開發人員控制什麼樣的查詢再從庫上來執行，因此比較靈活
     由程序直接連接誒數據庫，所以性能損耗比較少

缺點：增加了開發的工作量，使得程序代碼更爲複雜人爲控制，
     容易出現錯誤

中間件的讀寫分離(mysql-proxy、maxScale)

優點：中間件根據查詢語法的分析，自動完成讀寫分離；
     對程序透明，對已有的程序不用做任何的調整。

缺點：增加了中間層，所以對查詢效率有損耗；
     對於延遲敏感業務無法在主庫上執行

實現讀的負載均衡（具有相同角色的數據庫，如何共同分擔相同的負載）

軟件：LVS、Haproxy、MaxScale

硬件：F5

maxScale插件:

1. Authentication 認證插件
2. Protocal 協議插件
3. Router 路由插件（readconnroute、readwritesplit）
4. MOnitor 監控插件
5. Filter&Logging 日誌和過濾插件

maxScale實現讀寫分離及負載均衡

基於MySQL的架構優化

基於日誌點的複製配置的步驟：

基於GTID的複製配置的步驟：

常見的拓撲的設計及設計的注意事項:

MySQL複製性能的優化

MySQL複製常見的問題

MySQL主從複製無法解決的問題

利用主從複製搭建高可用的架構

MySQL數據庫的MMM架構

MMM架構的部署步驟

MMM集羣的優缺點：

MySQL數據庫的MHA架構

MHA架構的部署步驟

MHA集羣的優缺點：

數據庫的讀寫分離（如何在複製集羣的不同角色上，去執行不同的SQL語句）

實現讀的負載均衡（具有相同角色的數據庫，如何共同分擔相同的負載）

maxScale插件:

linux安裝cuda和cudnn

Mellanox網卡開啓SR-IOV

模擬手機設備：使用 Playwright 實現移動端自動化測試

全面系統的AI學習路徑，幫助普通人也能玩轉AI

HTML 00 Tutorial

uni-app實現上拉加載

vue3編譯優化之“靜態提升”

又是一個月-20240513

flask 如何保證返回json有序

linux服務器設置ssh免密

java中枚舉類的使用

關於js中的onclick事件和JQuery中的click方法以及on方法事件的詳解以及區別

MySQL知識點

SQL語句的優化

確定整數是否是迴文？空間O(1)時間複雜度O(logn)

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結