2. 程式人生 > >mysql 主從復制以及binlog 測試

mysql 主從復制以及binlog 測試

阿新 • • 發佈：2018-05-08
eba HA 可用 note 性能問題 ash 互為主從 add yum

###mysql查看binlog日誌內容

https://blog.csdn.net/nuli888/article/details/52106910

mysql的binlog日誌位置可通過show variables like ‘%datadir%‘;查看，直接打開無法查看，要看其內容2個辦法：


1、登錄到mysql查看binlog
只查看第一個binlog文件的內容
mysql> show binlog events;


查看指定binlog文件的內容
mysql> show binlog events in ‘mysql-bin.000002‘;

[python] view plain copy
  1. mysql> show binlog events in ‘mysql-bin.000001‘;
  2. +------------------+------+-------------+-----------+-------------+-----------------------------------------------------------+
  3. | Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
  4. +------------------+------+-------------+-----------+-------------+-----------------------------------------------------------+
  5. | mysql-bin.000001 | 4 | Format_desc | 195 | 106 | Server ver: 5.1.73-log, Binlog ver: 4 |
  6. | mysql-bin.000001 | 106 | Query | 195 | 198 | use `hadoop`; delete from user where id=3 |
  7. | mysql-bin.000001 | 198 | Intvar | 195 | 226 | INSERT_ID=4 |
  8. | mysql-bin.000001 | 226 | Query | 195 | 332 | use `hadoop`; INSERT INTO user (id,name)VALUES (NULL,1) |
  9. | mysql-bin.000001 | 332 | Query | 195 | 424 | use `hadoop`; delete from user where id=3 |
  10. | mysql-bin.000001 | 424 | Intvar | 195 | 452 | INSERT_ID=5 |
  11. | mysql-bin.000001 | 452 | Query | 195 | 560 | use `hadoop`; INSERT INTO user (id,name)VALUES (NULL,222) |
  12. | mysql-bin.000001 | 560 | Query | 195 | 660 | use `hadoop`; DELETE FROM `user` WHERE (`id`=‘1‘) |
  13. | mysql-bin.000001 | 660 | Intvar | 195 | 688 | INSERT_ID=6 |
  14. | mysql-bin.000001 | 688 | Query | 195 | 795 | use `hadoop`; INSERT INTO `user` (`name`) VALUES (‘555‘) |
  15. | mysql-bin.000001 | 795 | Intvar | 195 | 823 | INSERT_ID=7 |
  16. | mysql-bin.000001 | 823 | Query | 195 | 930 | use `hadoop`; INSERT INTO `user` (`name`) VALUES (‘555‘) |
  17. | mysql-bin.000001 | 930 | Intvar | 195 | 958 | INSERT_ID=8 |
  18. | mysql-bin.000001 | 958 | Query | 195 | 1065 | use `hadoop`; INSERT INTO `user` (`name`) VALUES (‘555‘) |
  19. | mysql-bin.000001 | 1065 | Intvar | 195 | 1093 | INSERT_ID=9 |
  20. | mysql-bin.000001 | 1093 | Query | 195 | 1200 | use `hadoop`; INSERT INTO `user` (`name`) VALUES (‘555‘) |
  21. | mysql-bin.000001 | 1200 | Query | 195 | 1300 | use `hadoop`; DELETE FROM `user` WHERE (`id`=‘9‘) |
  22. | mysql-bin.000001 | 1300 | Query | 195 | 1400 | use `hadoop`; DELETE FROM `user` WHERE (`id`=‘8‘) |
  23. | mysql-bin.000001 | 1400 | Query | 195 | 1500 | use `hadoop`; DELETE FROM `user` WHERE (`id`=‘7‘) |
  24. | mysql-bin.000001 | 1500 | Query | 195 | 1600 | use `hadoop`; DELETE FROM `user` WHERE (`id`=‘4‘) |
  25. | mysql-bin.000001 | 1600 | Query | 195 | 1700 | use `hadoop`; DELETE FROM `user` WHERE (`id`=‘5‘) |
  26. | mysql-bin.000001 | 1700 | Query | 195 | 1800 | use `hadoop`; DELETE FROM `user` WHERE (`id`=‘6‘) |
  27. | mysql-bin.000001 | 1800 | Intvar | 195 | 1828 | INSERT_ID=10 |
  28. | mysql-bin.000001 | 1828 | Query | 195 | 1935 | use `hadoop`; INSERT INTO `user` (`name`) VALUES (‘555‘) |
  29. | mysql-bin.000001 | 1935 | Intvar | 195 | 1963 | INSERT_ID=11 |
  30. | mysql-bin.000001 | 1963 | Query | 195 | 2070 | use `hadoop`; INSERT INTO `user` (`name`) VALUES (‘666‘) |
  31. | mysql-bin.000001 | 2070 | Intvar | 195 | 2098 | INSERT_ID=12 |
  32. | mysql-bin.000001 | 2098 | Query | 195 | 2205 | use `hadoop`; INSERT INTO `user` (`name`) VALUES (‘777‘) |
  33. +------------------+------+-------------+-----------+-------------+-----------------------------------------------------------+



查看當前正在寫入的binlog文件
mysql> show master status\G

[python] view plain copy
  1. mysql> show master status\G
  2. *************************** 1. row ***************************
  3. File: mysql-bin.000002
  4. Position: 106
  5. Binlog_Do_DB:
  6. Binlog_Ignore_DB: mysql,information_schema,performance_schema
  7. 1 row in set (0.00 sec)



獲取binlog文件列表
mysql> show binary logs;

[python] view plain copy
  1. mysql> show binary logs;
  2. +------------------+-----------+
  3. | Log_name | File_size |
  4. +------------------+-----------+
  5. | mysql-bin.000001 | 3548 |
  6. | mysql-bin.000002 | 106 |
  7. +------------------+-----------+
  8. 2 rows in set (0.00 sec)




2、用mysqlbinlog工具查看
基於開始/結束時間
[root@hd3 ~]# mysqlbinlog --start-datetime=‘2016-08-02 00:00:00‘ --stop-datetime=‘2016-08-03 23:01:01‘ -d hadoop /var/lib/mysql/mysql-bin.000001


基於pos值，註：hadoop是庫名，/var/lib/mysql/mysql-bin.000001是二進制文件路徑
[root@hd3 ~]# mysqlbinlog --start-position=2098 --stop-position=2205 -d hadoop /var/lib/mysql/mysql-bin.000001

[python] view plain copy
    1. /*!40019 SET @@session.max_insert_delayed_threads=0*/;
    2. /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
    3. DELIMITER /*!*/;
    4. # at 4
    5. #160803 17:49:51 server id 195 end_log_pos 106 Start: binlog v 4, server v 5.1.73-log created 160803 17:49:51 at startup
    6. # Warning: this binlog is either in use or was not closed properly.
    7. ROLLBACK/*!*/;
    8. BINLOG ‘
    9. P76hVw/DAAAAZgAAAGoAAAABAAQANS4xLjczLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    10. AAAAAAAAAAAAAAAAAAA/vqFXEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
    11. ‘/*!*/;
    12. # at 2098
    13. #160803 18:53:56 server id 195 end_log_pos 2205 Query thread_id=1481 exec_time=115 error_code=0
    14. use `hadoop`/*!*/;
    15. SET TIMESTAMP=1470221636/*!*/;
    16. SET @@session.pseudo_thread_id=1481/*!*/;
    17. SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
    18. SET @@session.sql_mode=0/*!*/;
    19. SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
    20. /*!\C utf8 *//*!*/;
    21. SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
    22. SET @@session.lc_time_names=0/*!*/;
    23. SET @@session.collation_database=DEFAULT/*!*/;
    24. INSERT INTO `user` (`name`) VALUES (‘777‘)
    25. /*!*/;
    26. DELIMITER ;
    27. # End of log file
    28. ROLLBACK /* added by mysqlbinlog */;
    29. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

###############22

https://www.cnblogs.com/1477717815fuming/p/8006143.html

公司規模已經形成，用戶數據已成為公司的核心命脈，一次老王一不小心把數據庫文件刪除，通過mysqldump備份策略恢復用了兩個小時，在這兩小時中，公司業務中斷，損失100萬，老王做出深刻反省，公司也因此對於數據庫的性能和可靠性提出更高要求。要求對數據庫進行改造，使其承載力進行提升，故障修復時間減少，有沒有能實現的方案呢？

數據庫常遇到的問題

一、性能問題

1、向上拓展 scale up ：針對單臺服務器，提高服務器的硬件性能，比如：內存，cpu等，個體本身 容易達到極限

2、向外拓展 scale out ：多臺服務器形成集群，共同完成一件事情

二、可用性問題

1、數據庫服務中斷

2、誤操作數據損壞

3、硬件故障

4、數據庫升級測試遭遇bug

5、黑客攻擊

數據庫高可用技術說明

高可用架構對於互聯網服務基本是標配，無論是應用服務還是數據庫服務都需要做到高可用。雖然互聯網服務號稱7*24小時不間斷服務，但多多少少有一些時候服務不可用，比如某些時候網頁打不開，百度不能搜索或者無法發微博，發微信等。一般而言，衡量高可用做到什麽程度可以通過一年內服務不可用時間作為參考，要做到3個9的可用性，一年內只能累計有8個小時不可服務，而如果要做到5個9的可用性，則一年內只能累計5分鐘服務中斷。所以雖說每個公司都說自己的服務是7*24不間斷的，但實際上能做到5個9的屈指可數，甚至根本做不到，國內互聯網巨頭BAT(百度，阿裏巴巴，騰訊)都有因為故障導致的停服問題。對於一個系統而言，可能包含很多模塊，比如前端應用，緩存，數據庫，搜索，消息隊列等，每個模塊都需要做到高可用，才能保證整個系統的高可用。對於數據庫服務而言，高可用可能更復雜，對用戶的服務可用，不僅僅是能訪問，還需要有正確性保證，因此，對於實現數據庫高可用，對互聯網公司來說極其重要！

企業級數據庫高可用架構圖

技術分享圖片

Mysql主從架構技術說明

Mysql內建的復制功能是構建大型，高性能應用程序的基礎。將Mysql的數據分布到多個系統上去，這種分布的機制，是通過將Mysql的某一臺主機（Master）的數據復制到其它主機（slaves）上，並重新執行一遍來實現的。復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日誌文件，這些日誌可以記錄發送到從服務器的更新。當一個從服務器連接主服務器時，它通知主服務器從服務器在日誌中讀取的最後一次成功更新的位置。從服務器接收從那時起發生的任何更新，然後封鎖並等待主服務器通知新的更新。

主從復制架構圖

技術分享圖片

數據庫復制特性

Mysql復制解決的問題

MySQL復制技術有以下一些特點：

(1) 數據分布 (Data distribution )

(2) 負載平衡(load balancing)

(3) 備份(Backups)

(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服務，要求版本一致

3、分別啟動兩臺服務器mysql服務，確保服務正常

三、實現步驟:

1、配置master主服務器

對master進行配置，包括打開二進制日誌，指定唯一的servr ID。例如，在配置文件加入如下值

vim /etc/my.cnf

server-id=1 #配置server-id，讓主服務器有唯一ID號（讓從服務器知道他的主服務器是誰）

log-bin=mysql-bin #打開Mysql日誌，日誌格式為二進制

skip-name-resolve#關閉名稱解析，（非必須）

然後重啟數據庫服務

systemctl restart mariadb

2．創建復制帳號

在Master的數據庫中建立一個備份帳戶：每個slave使用標準的MySQL用戶名和密碼連接master

。進行復制操作的用戶會授予REPLICATION SLAVE權限。（給從服務器授權，讓他能從主服務器拷貝二進制日誌）

mysql

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@‘192.168.10.%‘ IDENTIFIED BY ‘magedu‘;

3．查看主服務器狀態

在Master的數據庫執行show master status，查看主服務器二進制日誌狀態

技術分享圖片

4、配置slave從服務器

對slave進行配置，打開中繼日誌，指定唯一的servr ID，設置只讀權限。在配置文件加入如下值

vim /etc/my.cnf

server-id=2 #配置server-id，讓從服務器有唯一ID號

relay_log = mysql-relay-bin #打開Mysql日誌，日誌格式為二進制

read_only = 1 #設置只讀權限

log_bin = mysql-bin #開啟從服務器二進制日誌

log_slave_updates = 1 #使得更新的數據寫進二進制日誌中

然後重啟數據庫服務

systemctl restart mariadb

5．啟動從服務器復制線程

讓slave連接master，並開始重做master二進制日誌中的事件。

mysql

CHANGE MASTER TO MASTER_HOST=‘192.168.10.190‘,

MASTER_USER=‘slave‘,

MASTER_PASSWORD=‘magedu‘,

MASTER_LOG_FILE=‘mysql-bin.000001‘,

MASTER_LOG_POS=278;

執行start slave；# 啟動復制線程。

6、查看從服務器狀態

可使用SHOW SLAVE STATUS\G查看從服務器狀態，如下所示，也可用show processlist \G查看前復制狀態：

mysql

SHOW SLAVE STATUS\G

Slave_IO_Running: Yes #IO線程正常運行

Slave_SQL_Running: Yes #SQL線程正常運行

7.測試

理想的結果是在主服務器上添加的數據，在從服務器上也會同步

在主服務器上

技術分享圖片

技術分享圖片

在從服務器上

技術分享圖片

四、添加新slave服務器

假如master已經運行很久了，想對新安裝的slave進行數據同步，甚至它沒有master的數據。

此時，有幾種方法可以使slave從另一個服務開始，例如，從master拷貝數據，從另一個slave克隆，從最近的備份開始一個slave。為了加快Slave與master同步，可用以下方式先進行數據同步：

(1)master的某個時刻的數據快照；

(2)數據庫的備份數據

(3)master的二進制日誌文件。

實現主從從架構

也可以搭建主從從架構，讓從服務器之間進行復制

技術分享圖片

就是在從服務器也開啟二進制日誌，然後從的從I/O線程再將從的二進制日誌給拷貝過來寫入到自己的relay log中，然後sql線程再讀取relay log中的事件，在數據庫中執行，寫入到內存中。

Mysql復制過濾器

復制過濾器：

僅復制有限一個或幾個數據庫相關的數據，而非所有；由復制過濾器進行；

有兩種實現思路：

(1) 主服務器

主服務器僅向二進制日誌中記錄有關特定數據庫相關的寫操作；

binlog_do_db=

binlog_ignore_db=

(2) 從服務器

從服務器的SQL THREAD僅重放關註的數據庫或表相關的事件，並將其應用於本地；

Replicate_Do_DB=

Replicate_Ignore_DB=

企業常見數據庫架構

一、單一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

2> 查看show slave status \G;

3> 然後修改應用的連接地址。

(3) 用一個遠程的slave，用於災難恢復；

二、互為主從Master-Master(Master-Master in Active-Active Mode)

技術分享圖片

Master-Master復制的兩臺服務器，既是master，又是另一臺服務器的slave。這樣，任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。

即：在兩臺服務器上既執行master的操作又執行slave的操作（註意：兩臺數據庫都必須是可寫的）

互為主從復制過程

互為主從：兩個節點各自都要開啟binlog和relay log；

1、數據不一致；

2、自動增長id；

什麽是自增長ID？

對於某些唯一性的字段，可以通過設置自增長ID來實現,自增長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 #表示自增長字段從那個數開始

另一個節點使用偶數id

auto_increment_increment=2

auto_increment_offset=2

配置：

1、server_id必須要使用不同值；

2、均啟用binlog和relay log； read only = 0(因為互為主從，所以必須是可寫的)

3、存在自動增長id的表，為了使得id不相沖突，需要定義其自動增長方式；

服務啟動後執行如下兩步：

4、都授權有復制權限的用戶賬號；

5、各把對方指定為主節點；

實驗：數據庫互為主從復制步驟

1.修改mysql配置文件

一臺數據庫服務器上

vim /etc/my.cnf

server-id = 1

log_bin = mysql_bin

relay_log = relay-log

skip-name-resolve = on

log_slave_updates = 1

auto_increment_increment=2

auto_increment_offset=1

另一臺數據庫服務器上

vim /etc/my.cnf

server-id = 2

relay_log = relay-log

log_bin = mysql-log

skip-name-resolve = on

log_slave_updates = 1

auto_increment_increment=2

auto_increment_offset=2

修改完配置文件後，重啟數據庫服務

systemctl restart mariadb

2．創建復制帳號

分別在兩臺數據庫服務器上創建復制賬號

mysql

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@‘192.168.10.%‘ IDENTIFIED BY ‘magedu‘;

3．啟動從服務器復制線程

讓slave連接master，並開始重做master二進制日誌中的事件。

mysql

CHANGE MASTER TO MASTER_HOST=‘192.168.10.190‘,

MASTER_USER=‘slave‘,

MASTER_PASSWORD=‘magedu‘,

MASTER_LOG_FILE=‘mysql-bin.000001‘,

MASTER_LOG_POS=278;

執行start slave；# 啟動復制線程。

另一臺數據庫服務器也是如此

4、查看從服務器狀態

可使用SHOW SLAVE STATUS\G查看從服務器狀態，如下所示，也可用show processlist \G查看前復制態：

mysql

SHOW SLAVE STATUS\G

Slave_IO_Running: Yes #IO線程正常運行

Slave_SQL_Running: Yes #SQL線程正常運行

兩臺數據庫服務器都顯示如上結果就ok。

5.創建表，設置ID為自增長,兩邊插入數據看數據增長

在一臺數據庫服務器上

mysql

create database dnf;

use dnf;

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‘;

半同步復制：

semisync_master.so

semisync_slave.so

主節點：

INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;

MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;

+------------------------------------+-------+

| Variable_name | Value |

+------------------------------------+-------+

| 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;

stop slave;

start slave;

從節點：

INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;

MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;

+---------------------------------+-------+

| Variable_name | Value |

+---------------------------------+-------+

| 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;

stop slave;

start slave;

可查看從庫錯誤日誌觀察是否生效

master錯誤日誌

技術分享圖片

slave錯誤日誌

技術分享圖片

mysql優化：

1.可以用數據緩存，常見的memcache

2.數據庫本身有很多緩存機制，可使用對應的緩存策略

3.對數據來說，竟可能使用索引

4.對請求而言，可以實現讀寫分離，對讀請求負載均衡

5.對大數據庫或者表，可根據業務邏輯進行分庫分表

6.多有的優化，盡可能網內存中存放

分庫分表

分庫：當數據庫的數據非常龐大，可以把數據庫分成幾個數據庫，每個數據庫當一類數據，最後在拼接起來

分表：有兩種分法：

1.水平拆分：一個表中有10億條記錄，將這10億條記錄分成每10萬條記錄為一個表

2.垂直拆分：將一個字段或者多個字段分成一個表

mysql 主從復制以及binlog 測試

相關推薦

mysql 主從復制以及binlog 測試

eba HA 可用 note 性能問題 ash 互為主從 add yum ###mysql查看binlog日誌內容 https://blog.csdn.net/nuli888/article/details/52106910 mysql的binlog日誌位置可通過sho

Mysql主從復制以及常見錯誤問題分析

ase min transacti 無法 bin ger datadir mysql主從 mysql配置 Mysql主從復制以及常見錯誤問題分析一、主從復制簡介：1、mysql

MySQL主從復制原理以及架構

body 觸發器 新的 dex 延時 -m 加鎖 影響 int 1 復制概述 Mysql內建的復制功能是構建大型，高性能應用程序的基礎。將Mysql的數據分布到多個系統上去，這種分布的機制，是通過將Mysql的某一臺主機的 數據復制到其它主機（slaves）上

mysql主從復制

值變化 -- stat 可能 inf 地址 base 數據 waiting 1、主從服務器分別作以下操作： 1.1、版本一致 1.2、初始化表，並在後臺啟動mysql 1.3、修改root的密碼2、修改主服務器master: #vi /etc/my.cnf

MySQL主從復制原理深入解析與練習

數據庫 記錄 sql語句 change master MySQL主從復制原理深入解析與練習MySQL主從復制畫圖描述：MySQL主從復制原理上圖詳解：①　用戶做crud操作，寫入數據庫，更新結果記錄到binlog中；②　主從同步是主找從的，從庫IO發起請求，主庫的主進程看從庫的master

mysql 主從復制配置

安裝 connect 生成 for ica www cte 數據庫服務 grant 二、MySQL主從復制場景描述：主數據庫服務器：192.168.10.130，MySQL已經安裝，並且無應用數據。從數據庫服務器：192.168.10.131，MySQL已經安裝，並且無

MySQL 主從復制擴展

blog height spa 擴展 html htm mysql 主從 bin 策略 (1) 主庫的線程狀態 (2) 從庫的線程狀態 (3) MySQL 主從復制備份策略 (4) MySQL 主從復制延遲問題 (5) 讓從庫記錄 binlog 日誌

Mysql 主從復制 及 一些要註意的特殊設置

數據庫 配置文件 主從復制 主從模式 0.準備A.安裝數據庫： 主從mysql數據庫 （mysql server）都安裝好：版本上，mysql 允許 低版本master 配 高版本slavehttps://dev.mysql.com/doc/refman/5.7/en/replication-

2-16 mysql主從復制

完整 version tab arc pos binlog data red community 2-16 mysql主從復制 1. 部署MYSQL主從同步 <M-S> 環境：mysql版本一致，均為5.7.18 master xuegod4

mysql主從復制讀寫分離

mysql主從 mysql讀寫分離 mysql主從復制讀寫分離一、MYSQL讀寫分離的概述Mysql作為目前世界上使用最廣泛的免費數據庫，相信所有從事系統運維的工程師都一定接觸過。但在實際的生產環境中，由單臺Mysql作為獨立的數據庫是完全不能滿足實際需求的，無論是在安全性，高可用性以及高並發等各個方

Ansible 管理MySQL主從復制

unit class border moni 必須 aml conn scala body mysql_replication - 管理MySQL復制 1.3版新功能 概要 要求（在執行模塊的主機上） 選項 例子 筆記 狀態 支持 概要 管理MySQL

mysql主從復制配置

服務 ssh auto mysqld 實時數據 配置 均衡 t_sql ges 同步原理： 同步時從庫由兩個線程完成（IO,SQL），主庫由一個線程完成（IO）； 要把主庫的數據先還原到從庫，主庫備份的點就是從庫change master的點，或者使用參數--master

MySQL主從復制（一）

mysql mysql主從 web一般是拒絕用戶上傳的，webdav可以實現數據上傳MySQL的擴展方式：scale up：scale out：一、MySQL的擴展：復制：每個node都有相同的數據集從node請求主node的二進制日誌，在本地進行重放實現復制的作用：數據分布：負載均衡：//讀均衡，寫

MySQL主從復制Galera

主從復制 galera cluster 多線程復制 gtid 一、主從復制的問題和解決方案二、Galera Cluster三、MySQL 5.6的多線程復制、GTID MySQL Replication： Master HA或多主節點模型 MMM：multi master MySQL M

MySQL主從復制與讀寫分離

$0 get 登錄 nice ica oca kcon 過程 ads 主從復制(Master-Slave)與讀寫分離(Mysql作為目前世界上使用最廣泛的免費數據庫，相信所有從事系統運維的工程師都一定接觸過。但在實際的生產環境中，由單臺主從復制（Master-Slave）

mysql主從復制實戰——詳細

mysqlmysql主從原理：1）至少需要2臺數據庫服務器，一主一從，master開啟bin-log功能。（bin-log功能用戶記錄主控增 加、刪除、修改、更新SQL的語句。) 2)異步復制的過程，有延遲，毫秒級別（延遲和你的網絡和性能、數據庫的量級有關），開啟3個線程。分別是maste

zabbix監控mysql主從復制

zabbix監控mysql主從復制 zabbix mysql5.6zabbix監控mysql主從復制.監控MySQL的復制原理：利用在slave上運行show slave status獲取Slave_IO_Running和Slave_SQL_Running的值1.在mysql上新建監控用戶 grant r

MySQL主從復制的實現過程

36-6 備份 出現 傳輸 size 無法 con 行數據 排版 一、什麽是主從復制 將主數據庫中的DDL和DML操作通過二進制日誌（BINLOG）傳輸到從數據庫上，然後將這些日誌重新執行（重做）；從而使得從數據庫的數據與主數據庫保持一致。 二、主從復制的作用 1、主數據庫

MySQL主從復制技術與讀寫分離技術amoeba應用

buffer chan lns -a query rep 下載 高可用性 tab MySQL主從復制技術與讀寫分離技術amoeba應用 前言：眼下在搭建一個人才站點，估計流量會非常大，須要用到分布式數據庫技術，MySQL的主從復制+讀寫分

Linux下MySQL主從復制（二）

mysql 鄰居 MySQL的一主多從模式原理結構圖配置步驟1.主服務器： 1. 改變server id 2. 啟用二進制日誌文件 3. 創建具有復制的用戶123123具體操作請看：http://www.crazyrui.pw:8088/index.php/2017/07/23/linux_m