IP的設置:A主機 IP:10.10.0.119;Mask:255.255.0.0;B主機 IP:10.10.8.112;Mask:255.255.0.0

創(chuàng)新互聯(lián)是一家專業(yè)提供福清企業(yè)網站建設,專注與成都網站設計、網站建設、H5技術、小程序制作等業(yè)務。10年已為福清眾多企業(yè)、政府機構等服務。創(chuàng)新互聯(lián)專業(yè)網站制作公司優(yōu)惠進行中。
在IP設置完成以后,需要確定兩主機的防火墻確實已經關閉。可以使用命令service iptables status查看防火墻狀態(tài)。如果防火墻狀態(tài)。
為仍在運行。使用service iptables stop來停用防火墻。如果想啟動關閉防火墻,可以使用setup命令來禁用或定制。最終以兩臺主機可以相互ping通為佳。
3.2 配置A主(master) B從(slave)模式;3.2.1 配置A 為master。
增加一個用戶同步使用的帳號:
GRANT FILE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’;
GRANTREPLICATION SLAVE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’。
賦予10.10.8.112也就是Slave機器有File權限,只賦予Slave機器有File權限還不行,還要給它REPLICATION SLAVE的權限才可以。
增加一個數據庫作為同步數據庫:create database test;
創(chuàng)建一個表結構:create table mytest (username varchar(20),password varchar(20));
修改配置文件:修改A的/etc/my.cnf文件。
在my.cnf配置項中加入下面配置:
server-id = 1 #Server標識
log-bin
binlog-do-db=test #指定需要日志的數據庫
重起數據庫服務:
service mysqld restart
查看server-id:
show variable like ‘server_id’。
在[mysqld]配置段添加如下字段
使用master狀態(tài)
show master status; 記錄file和position的值
在[mysqld]配置段添加如下字段,
連接slave,在mysql命令行執(zhí)行以下命令,設置參數,啟動slave
MASTER_LOG_FILE 對應master的status的file
MASTER_LOG_POS 對應master的status的position
主要查看Slave_IO_Running和Slave_SQL_Running 兩列是否都為YES
mysql主從同步的步驟
一、主機環(huán)境
主機:
master操作系統(tǒng):rhel6.0
IP:172.16.0.100
MySQL版本:5.1.47
從機:
slave操作系統(tǒng):rhel6.0
IP:172.16.0.200
MySQL版本:5.1.47
二、創(chuàng)建數據庫
分別登錄master機和slave機的mysql:mysql –u root –p
創(chuàng)建數據庫:create database repl;
三、master機和slave機的相關配置
1、修改master機器中mysql配置文件my.cnf,該文件在/etc目錄下
在[mysqld]配置段添加如下字段
server-id=1
log-bin=mysql-bin
binlog-do-db=repl //需要同步的數據庫,如果沒有本行,即表示同步所有的數據庫
binlog-ignore-db=mysql //被忽略的數據庫
在master機上為slave機添加一同步帳號
grant replication slave on *.* to 'replication'@'172.16.0.200' identified by '123456';
重啟master機的mysql服務:service mysqld restart
用show master status 命令看日志情況
mysqlshow master status;
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
| log.000003 | 98 | repl | mysql |
1 row in set (0.00 sec)
2、修改slave機中mysql配置文件
同樣在[mysqld]字段下添加如下內容
server-id=2
master-host=172.16.0.100
master-user=repl
master-password=123456
master-port=3306
master-connect-retry=60
replicate-do-db=repl //同步的數據庫,不寫本行 表示 同步所有數據庫
然后重啟slave機的mysql
在slave機中進入mysql
mysqlstart slave;
mysqlshow slave status\G;
如果Slave_IO_Running、Slave_SQL_Running狀態(tài)為Yes則表明設置成功。
這時 再執(zhí)行show slave status\G
實際是主從配置的擴展,例如有兩臺機器a1,a2,主從模式為a1(M)-a2(S),雙主模式就是a1-a2,然后a2-a1
這樣,當任意一臺掛掉的時候,其中一臺可以完全負擔起讀和寫的任務。
**創(chuàng)建主節(jié)點用戶供從節(jié)點拉取數據用(62-215)
同主
修改用戶名密碼
賬號登陸
同主
(62做從節(jié)點從215拉數據的賬號)
雙主至此配置完成,其實就是先配置a-b,在配置b-a
注意,每次重啟mysql服務以后,需要重新執(zhí)行start slave命令
MySQL 主從一直是面試常客,里面的知識點雖然基礎,但是能回答全的同學不多。
比如樓哥之前面試小米,就被問到過主從復制的原理,以及主從延遲的解決方案,因為回答的非常不錯,給面試官留下非常好的印象。你之前面試,有遇到過哪些 MySQL 主從的問題呢?
所謂 MySQL 主從,就是建立兩個完全一樣的數據庫,一個是主庫,一個是從庫, 主庫對外提供讀寫的操作,從庫對外提供讀的操作 ,下面是一主一從模式:
對于數據庫單機部署,在 4 核 8G 的機器上運行 MySQL 5.7 時,大概可以支撐 500 的 TPS 和 10000 的 QPS, 當遇到一些活動時,查詢流量驟然,就需要進行主從分離。
大部分系統(tǒng)的訪問模型是讀多寫少,讀寫請求量的差距可能達到幾個數量級,所以我們可以通過一主多從的方式, 主庫只負責寫入和部分核心邏輯的查詢,多個從庫只負責查詢,提升查詢性能,降低主庫壓力。
MySQL 主從還能做到服務高可用,當主庫宕機時,從庫可以切成主庫,保證服務的高可用,然后主庫也可以做數據的容災備份。
整體場景總結如下:
MySQL 的主從復制是依賴于 binlog 的,也就是記錄 MySQL 上的所有變化并以二進制形式保存在磁盤上二進制日志文件。
主從復制就是將 binlog 中的數據從主庫傳輸到從庫上,一般這個過程是異步的,即主庫上的操作不會等待 binlog 同步的完成。
詳細流程如下:
當主庫和從庫數據同步時,突然中斷怎么辦?因為主庫與從庫之間維持了一個長鏈接,主庫內部有一個線程,專門服務于從庫的這個長鏈接的。
對于下面的情況,假如主庫執(zhí)行如下 SQL,其中 a 和 create_time 都是索引:
我們知道,數據選擇了 a 索引和選擇 create_time 索引,最后 limit 1 出來的數據一般是不一樣的。
所以就會存在這種情況:在 binlog = statement 格式時,主庫在執(zhí)行這條 SQL 時,使用的是索引 a,而從庫在執(zhí)行這條 SQL 時,使用了索引 create_time,最后主從數據不一致了。
那么我們改如何解決呢?
可以把 binlog 格式修改為 row,row 格式的 binlog 日志記錄的不是 SQL 原文,而是兩個 event:Table_map 和 Delete_rows。
Table_map event 說明要操作的表,Delete_rows event用于定義要刪除的行為,記錄刪除的具體行數。 row 格式的 binlog 記錄的就是要刪除的主鍵 ID 信息,因此不會出現主從不一致的問題。
但是如果 SQL 刪除 10 萬行數據,使用 row 格式就會很占空間的,10 萬條數據都在 binlog 里面,寫 binlog 的時候也很耗 IO。但是 statement 格式的 binlog 可能會導致數據不一致。
設計 MySQL 的大叔想了一個折中的方案,mixed 格式的 binlog,其實就是 row 和 statement 格式混合使用, 當 MySQL 判斷可能數據不一致時,就用 row 格式,否則使用就用 statement 格式。
有時候我們遇到從數據庫中獲取不到信息的詭異問題時,會糾結于代碼中是否有一些邏輯會把之前寫入的內容刪除,但是你又會發(fā)現,過了一段時間再去查詢時又可以讀到數據了,這基本上就是主從延遲在作怪。
主從延遲,其實就是“從庫回放” 完成的時間,與 “主庫寫 binlog” 完成時間的差值, 會導致從庫查詢的數據,和主庫的不一致 。
談到 MySQL 數據庫主從同步延遲原理,得從 MySQL 的主從復制原理說起:
總結一下主從延遲的主要原因 :主從延遲主要是出現在 “relay log 回放” 這一步,當主庫的 TPS 并發(fā)較高,產生的 DDL 數量超過從庫一個 SQL 線程所能承受的范圍,那么延時就產生了,當然還有就是可能與從庫的大型 query 語句產生了鎖等待。
我們一般會把從庫落后的時間作為一個重點的數據庫指標做監(jiān)控和報警,正常的時間是在毫秒級別,一旦落后的時間達到了秒級別就需要告警了。
解決該問題的方法,除了縮短主從延遲的時間,還有一些其它的方法,基本原理都是盡量不查詢從庫。
具體解決方案如下:
在實際應用場景中,對于一些非常核心的場景,比如庫存,支付訂單等,需要直接查詢從庫,其它非核心場景,就不要去查主庫了。
兩臺機器 A 和 B,A 為主庫,負責讀寫,B 為從庫,負責讀數據。
如果 A 庫發(fā)生故障,B 庫成為主庫負責讀寫,修復故障后,A 成為從庫,主庫 B 同步數據到從庫 A。
一臺主庫多臺從庫,A 為主庫,負責讀寫,B、C、D為從庫,負責讀數據。
如果 A 庫發(fā)生故障,B 庫成為主庫負責讀寫,C、D負責讀,修復故障后,A 也成為從庫,主庫 B 同步數據到從庫 A。
網站題目:包含mysql主從同步怎么做的詞條
標題來源:http://chinadenli.net/article34/hsgdpe.html
成都網站建設公司_創(chuàng)新互聯(lián),為您提供虛擬主機、面包屑導航、全網營銷推廣、網站設計公司、服務器托管、做網站
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)