查看mysql是否為雙機

mysql雙機熱備實現原理分析，在本文經過深思熟慮和多次用不同的方式實測試后。最后在這篇文章中，用一個小例子來完成mysql雙機熱備的實現。

成都創新互聯公司成都網站建設按需制作，是成都網站營銷公司,為不銹鋼雕塑提供網站建設服務,有成熟的網站定制合作流程，提供網站定制設計服務：原型圖制作、網站創意設計、前端HTML5制作、后臺程序開發等。成都網站維護熱線：028-86922220

Mysql數據庫沒有增量備份的機制，當數據量太大的時候備份是一個很大的問題。還好mysql數據庫提供了一種主從備份的機制，其實就是把主數據庫的所有的數據同時寫到備份的數據庫中。實現mysql數據庫的熱備份。

要想實現雙機的熱備，首先要了解主從數據庫服務器的版本的需求。要實現熱備mysql的版本都高于3.2。還有一個基本的原則就是作為從數據庫的數據版本可以高于主服務器數據庫的版本，但是不可以低于主服務器的數據庫版本。

當然要實現mysql雙機熱備，除了mysql本身自帶的REPLICATION功能可以實現外，也可以用Heartbeat這個開源軟件來實現。不過本文主要還是講如何用mysql自帶的REPLICATION來實現mysql雙機熱備的功能。

1. 準備服務器

由于Mysql不同版本之間的（二進制日志）binlog格式可能會不太一樣，因此最好的搭配組合是主（Master）服務器的Mysql版本和從（Slave）服務器版本相同或者更低，主服務器的版本肯定不能高于從服務器版本。

本次我用于測試的兩臺服務器版本都是Mysql-5.5.17。

2. Mysql 建立主－從服務器雙機熱備配置步驟

2.1環境描述

A服務器（主服務器Master）：59.151.15.36

B服務器（從服務器Slave）：218.206.70.146

主從服務器的Mysql版本皆為5.5.17

Linux環境下

將主服務器需要同步的數據庫內容進行備份一份，上傳到從服務器上，保證始初時兩服務器中數據庫內容一致。

不過這里說明下，由于我是利用Mysql在安裝后就有的數據庫test進行測試的，所以兩臺服務器里面是沒有建立表的，只不分別在test里面建立了同樣的一張空表tb_mobile;

Sql語句如下：

mysql create table tb_mobile( mobile VARCHAR(20) comment'手機號碼', time timestamp DEFAULT now() comment'時間' );

2.2 主服務器Master配置

2.2.1 創建同步用戶

進入mysql操作界面，在主服務器上為從服務器建立一個連接帳戶，該帳戶必須授予REPLICATION SLAVE權限。因為從mysql版本3.2以后就可以通過REPLICATION對其進行雙機熱備的功能操作。

操作指令如下：

mysql grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456';

mysql flush privileges;

創建好同步連接帳戶后，我們可以通過在從服務器（Slave）上用replicat帳戶對主服務器（Master）數據庫進行訪問下，看下是否能連接成功。

在從服務器（Slave）上輸入如下指令：

[root@YD146 ~]# mysql -h59.151.15.36 -ureplicate -p123456

如果出現下面的結果，則表示能登錄成功，說明可以對這兩臺服務器進行雙機熱備進行操作。

2.2.2 修改mysql配置文件

如果上面的準備工作做好，那邊我們就可以進行對mysql配置文件進行修改了，首先找到mysql配置所有在目錄，一般在安裝好mysql服務后，都會將配置文件復制一一份出來放到/ect目錄下面，并且配置文件命名為：my.cnf。即配置文件準確目錄為/etc/my.cnf

(Linux下用rpm包安裝的MySQL是不會安裝/etc/my.cnf文件的，

至于為什么沒有這個文件而MySQL卻也能正常啟動和作用，在點有兩個說法，

第一種說法，my.cnf只是MySQL啟動時的一個參數文件，可以沒有它，這時MySQL會用內置的默認參數啟動，

第二種說法，MySQL在啟動時自動使用/usr/share/mysql目錄下的my-medium.cnf文件，這種說法僅限于rpm包安裝的MySQL，

解決方法，只需要復制一個/usr/share/mysql目錄下的my-medium.cnf文件到/etc目錄，并改名為my.cnf即可。)

找到配置文件my.cnf打開后，在[mysqld]下修改即可：

[mysqld]

server-id = 1

log-bin=mysql-bin //其中這兩行是本來就有的，可以不用動，添加下面兩行即可

binlog-do-db = test

binlog-ignore-db = mysql

2.2.3 重啟mysql服務

修改完配置文件后，保存后，重啟一下mysql服務，如果成功則沒問題。

2.2.4 查看主服務器狀態

進入mysql服務后，可通過指令查看Master狀態，輸入如下指令：

注意看里面的參數，特別前面兩個File和Position，在從服務器（Slave）配置主從關系會有用到的。

注：這里使用了鎖表，目的是為了產生環境中不讓進新的數據，好讓從服務器定位同步位置，初次同步完成后，記得解鎖。

2.3 從服務器Slave配置

2.3.1修改配置文件

因為這里面是以主－從方式實現mysql雙機熱備的，所以在從服務器就不用在建立同步帳戶了，直接打開配置文件my.cnf進行修改即可，道理還是同修改主服務器上的一樣，只不過需要修改的參數不一樣而已。如下：

[mysqld]

server-id = 2

log-bin=mysql-bin

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

2.3.2重啟mysql服務

修改完配置文件后，保存后，重啟一下mysql服務，如果成功則沒問題。

2.3.3用change mster 語句指定同步位置

這步是最關鍵的一步了，在進入mysql操作界面后，輸入如下指令：

mysqlstop slave; //先停步slave服務線程，這個是很重要的，如果不這樣做會造成以下操作不成功。

mysqlchange master to

master_host='59.151.15.36',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000016 ',master_log_pos=107;

注：master_log_file, master_log_pos由主服務器（Master）查出的狀態值中確定。也就是剛剛叫注意的。master_log_file對應File, master_log_pos對應Position。Mysql 5.x以上版本已經不支持在配置文件中指定主服務器相關選項。

遇到的問題，如果按上面步驟之后還出現如下情況：

則要重新設置slave。指令如下

mysqlstop slave;

mysqlreset slave;

之后停止slave線程重新開始。成功后，則可以開啟slave線程了。

mysqlstart slave;

2.3.4查看從服務器（Slave）狀態

用如下指令進行查看

mysql show slave status\G;

查看下面兩項值均為Yes，即表示設置從服務器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

2.4 測試同步

之前開始已經說過了在數據庫test只有一個表tb_mobile沒有數據，我們可以先查看下兩服務器的數據庫是否有數據：

Master:59.151.15.36

Slave:218.206.70.146

好了，現在可以在Master服務器中插入數據看下是否能同步。

Master:59.151.15.36

Slave:218.206.70.146

可以從上面兩個截圖上看出，在Master服務器上進行插入的數據在Slave服務器可以查到，這就表示雙機熱備配置成功了。

3. Mysql 建立主－主服務器雙機熱備配置步驟

服務器還是用回現在這兩臺服務器

3.1創建同步用戶

同時在主從服務器建立一個連接帳戶，該帳戶必須授予REPLIATION SLAVE權限。這里因為服務器A和服務器B互為主從，所以都要分別建立一個同步用戶。

服務器A：

mysql grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456';

mysql flush privileges;

服務器B：

mysql grant replication slave on *.* to 'replicate'@'59.151.15.36' identified by '123456';

mysql flush privileges;

3.2修改配置文件my.cnf

服務器A

[mysqld]

server-id = 1

log-bin=mysql-bin

binlog-do-db = test

binlog-ignore-db = mysql

#主－主形式需要多添加的部分

log-slave-updates

sync_binlog = 1

auto_increment_offset = 1

auto_increment_increment = 2

replicate-do-db = test

replicate-ignore-db = mysql,information_schema

服務器B：

[mysqld]

server-id = 2

log-bin=mysql-bin

master-slave need

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

#主－主形式需要多添加的部分

binlog-do-db = test

binlog-ignore-db = mysql

log-slave-updates

sync_binlog = 1

auto_increment_offset = 2

auto_increment_increment = 2

3.3分別重啟A服務器和B服務器上的mysql服務

重啟服務器方式和上面的一樣，這里就不做講解了。

3.4分別查A服務器和B服務器作為主服務器的狀態

服務器A：

服務器B：

3.5分別在A服務器和B服務器上用change master to 指定同步位置

服務器A：

mysqlchange master to

master_host='218.206.70.146',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000011 ',master_log_pos=497;

服務器B：

mysqlchange master to

master_host='59.151.15.36',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000016 ',master_log_pos=107;

3.6 分別在A和B服務器上重啟從服務線程

mysqlstart slave;

3.7 分別在A和B服務器上查看從服務器狀態

mysqlshow slave status\G;

查看下面兩項值均為Yes，即表示設置從服務器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

3.8 測試主－主同步例子

測試服務器A：

在服務器A上插入一條語句如下圖所示：

之后在服務器B上查看是否同步如下圖所示：

測試服務器B：

在服務器B上插入一條語句如下圖所示：

然后在從服務器A上查看是否有同步數據如下圖所示：

最后從結果可以看出主－主形式的雙機熱備是能成功實現的。

4. 配置參數說明

Server-id

ID值唯一的標識了復制群集中的主從服務器，因此它們必須各不相同。Master_id必須為1到232－1之間的一個正整數值，slave_id值必須為2到232－1之間的一個正整數值。

Log-bin

表示打開binlog，打開該選項才可以通過I/O寫到Slave的relay-log，也是可以進行replication的前提。

Binlog-do-db

表示需要記錄二進制日志的數據庫。如果有多個數據可以用逗號分隔，或者使用多個binlog-do-dg選項。

Binglog-ingore-db

表示不需要記錄二進制日志的數據庫，如果有多個數據庫可用逗號分隔，或者使用多binglog-ignore-db選項。

Replicate-do-db

表示需要同步的數據庫，如果有多個數據可用逗號分隔，或者使用多個replicate-do-db選項。

Replicate-ignore-db

表示不需要同步的數據庫，如果有多個數據庫可用逗號分隔，或者使用多個replicate-ignore-db選項。

Master-connect-retry

master-connect-retry=n表示從服務器與主服務器的連接沒有成功，則等待n秒（s）后再進行管理方式（默認設置是60s）。如果從服務器存在mater.info文件，它將忽略些選項。

Log-slave-updates

配置從庫上的更新操作是否寫入二進制文件，如果這臺從庫，還要做其他從庫的主庫，那么就需要打這個參數，以便從庫的從庫能夠進行日志同步。

Slave-skip-errors

在復制過程，由于各種原因導致binglo中的sql出錯，默認情況下，從庫會停止復制，要用戶介入。可以設置slave-skip-errors來定義錯誤號，如果復制過程中遇到的錯誤是定義的錯誤號，便可以路過。如果從庫是用來做備份，設置這個參數會存在數據不一致，不要使用。如果是分擔主庫的查詢壓力，可以考慮。

Sync_binlog=1 Or N

Sync_binlog的默認值是0，這種模式下，MySQL不會同步到磁盤中去。這樣的話，Mysql依賴操作系統來刷新二進制日志binary log，就像操作系統刷新其他文件的機制一樣。因此如果操作系統或機器（不僅僅是Mysql服務器）崩潰，有可能binlog中最后的語句丟失了。要想防止這種情況，可以使用sync_binlog全局變量，使binlog在每N次binlog寫入后與硬盤同步。當sync_binlog變量設置為1是最安全的，因為在crash崩潰的情況下，你的二進制日志binary log只有可能丟失最多一個語句或者一個事務。但是，這也是最慢的一種方式（除非磁盤有使用帶蓄電池后備電源的緩存cache,使得同步到磁盤的操作非常快）。

即使sync_binlog設置為1，出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。如果使用InnoDB表，Mysql服務器處理COMMIT語句，它將整個事務寫入binlog并將事務提交到InnoDB中。如果在兩次操作之間出現崩潰，重啟時，事務被InnoDB回滾，但仍然存在binlog中。可以用-innodb-safe-binlog選項來增加InnoDB表內容和binlog之間的一致性。（注釋：在Mysql 5.1版本中不需要-innodb-safe-binlog；由于引入了XA事務支持，該選項作廢了），該選項可以提供更大程度的安全，使每個事務的binlog(sync_binlog=1)和（默認情況為真）InnoDB日志與硬盤同步，該選項的效果是崩潰后重啟時，在滾回事務后，Mysql服務器從binlog剪切回滾的InnoDB事務。這樣可以確保binlog反饋InnoDB表的確切數據等，并使從服務器保持與主服務器保持同步（不接收回滾的語句）。

Auto_increment_offset和Auto_increment_increment

Auto_increment_increment和auto_increment_offset用于主－主服務器（master-to-master）復制，并可以用來控制AUTO_INCREMENT列的操作。兩個變量均可以設置為全局或局部變量，并且假定每個值都可以為1到65,535之間的整數值。將其中一個變量設置為0會使該變量為1。

這兩個變量影響AUTO_INCREMENT列的方式：auto_increment_increment控制列中的值的增量值，auto_increment_offset確定AUTO_INCREMENT列值的起點。

如果auto_increment_offset的值大于auto_increment_increment的值，則auto_increment_offset的值被忽略。例如：表內已有一些數據，就會用現在已有的最大自增值做為初始值。

主備原理

備庫 B 跟主庫 A 之間維持了一個長連接。主庫 A 內部有一個線程，專門用于服務備庫 B 的這個長連接。一個事務日志同步的完整過程是這樣的：

1、在備庫 B 上通過 change master 命令，設置主庫 A 的 IP、端口、用戶名、密碼，以及要從哪個位置開始請求 binlog，這個位置包含文件名和日志偏移量。

2、在備庫 B 上執行 start slave 命令，這時候備庫會啟動兩個線程，就是圖中的 io_thread 和 sql_thread 。其中 io_thread 負責與主庫建立連接。

3、主庫 A 校驗完用戶名、密碼后，開始按照備庫 B 傳過來的位置，從本地讀取 binlog， 發給 B(push模式) 。

4、備庫 B 拿到 binlog 后，寫到本地文件，稱為中轉日志（ relay log ）。

5、sql_thread 讀取中轉日志，解析出日志里的命令，并執行。

這里需要說明，后來由于多線程復制方案的引入， sql_thread 演化成為了多個線程。

binlog 的三種格式對比：

一種是 statement，按語句進行數據備份，可能需要聯系上下文，日志相對較少 ，一種是 row，按行記錄對數據的修改，無需關心sql語句或者上下文，邏輯簡單，日志文件巨大，性能相對較低 。還有第三種格式，叫作 mixed ，其實它就是前兩種格式的 混合 。

show variables like ' binlog_format '; 該參數控制。

1、因為有些 statement 格式的 binlog 可能會導致主備不一致 ，所以要使用 row 格式。

2、但 row 格式的缺點是， 很占空間 。比如你用一個 delete 語句刪掉 10 萬行數據，用 statement 的話就是一個 SQL 語句被記錄到 binlog 中，占用幾十個字節的空間。但如果用 row 格式的 binlog，就要把這 10 萬條記錄都寫到 binlog 中。這樣做，不僅會占用更大的空間，同時寫 binlog 也要耗費 IO 資源，影響執行速度。

3、MySQL 就取了個折中方案，也就是有了 mixed 格式的 binlog。mixed 格式的意思是，MySQL 自己會判斷這條 SQL 語句是否可能引起主備不一致，如果有可能，就用 row 格式，否則就用 statement 格式。也就是說，mixed 格式可以利用 statment 格式的優點，同時又避免了數據不一致的風險。

越來越推薦row格式，因為它方便恢復數據 。

備庫： show slave status\G? 查看備庫情況， seconds_behind_master 主備延時，理想狀況為0.

1、機器異構，備庫性能差或者集中在一個機器上。

2、忽視備庫壓力，對備庫使用沒有節制，比如復雜的讀計算。

1、一主多從。除了備庫外，可以多接幾個從庫，讓這些從庫來分擔讀的壓力。

2、通過 binlog 輸出到外部系統，比如 Hadoop 這類系統，讓外部系統提供統計類查詢的能力。

在主庫上，影響并發度的原因就是各種鎖了。

在備庫上，就是圖中備庫上 sql_thread 更新數據 (DATA) 的邏輯。如果是用 單線程 的話，就會導致備庫應用日志不夠快，造成主備延遲。

官方 MySQL5.6 版本 ，支持了并行復制，只是支持的粒度是 按庫并行 。這個策略的并行效果，取決于壓力模型。如果在主庫上有多個 DB，并且 各個 DB 的壓力均衡 ，使用這個策略的效果會很好。

相比于 按表 和 按行 分發，這個策略有兩個優勢：

1、構造 hash 值的時候很快，只需要庫名；而且一個實例上 DB 數也不會很多，不會出現需要構造 100 萬個項這種情況。

2、不要求 binlog 的格式。因為 statement 格式的 binlog 也可以很容易拿到庫名。

但是，如果你的主庫上的表都放在同一個 DB 里面，這個策略就沒有效果了；或者如果不同 DB 的熱點不同，比如一個是業務邏輯庫，一個是系統配置庫，那也起不到并行的效果。

理論上你可以創建不同的 DB，把相同熱度的表均勻分到這些不同的 DB 中，強行使用這個策略。不過據我所知，由于需要特地移動數據，這個策略用得并不多。

在 MariaDB 并行復制實現之后， 官方的 MySQL5.7 版本也提供了類似的功能，由參數 s lave-parallel-type 來控制并行復制策略：

1、配置為 DATABASE ，表示使用 MySQL 5.6 版本的按庫并行策略；

2、配置為 LOGICAL_CLOCK ，表示的就是類似 MariaDB 的策略。不過，MySQL 5.7 這個策略，針對并行度做了優化。這個優化的思路也很有趣兒。

在 2018 年 4 月份發布的 MySQL 5.7.22 版本里，MySQL 增加了一個新的并行復制策略，基于 WRITESET 的并行復制。

相應地，新增了一個參數 binlog-transaction-dependency-tracking ，用來控制是否啟用這個新策略。這個參數的可選值有以下三種。

1、COMMIT_ORDER，表示的就是前面介紹的，根據同時進入 prepare 和 commit 來判斷是否可以并行的策略。

2、WRITESET，表示的是對于事務涉及更新的每一行，計算出這一行的 hash 值，組成集合 writeset。如果兩個事務沒有操作相同的行，也就是說它們的 writeset 沒有交集，就可以并行。

3、WRITESET_SESSION，是在 WRITESET 的基礎上多了一個約束，即在主庫上同一個線程先后執行的兩個事務，在備庫執行的時候，要保證相同的先后順序。

當然為了唯一標識，這個 hash 值是通過“庫名 + 表名 + 索引名 + 值”計算出來的。如果一個表上除了有主鍵索引外，還有其他唯一索引，那么對于每個唯一索引，insert 語句對應的 writeset 就要多增加一個 hash 值。

你可能看出來了，這跟我們前面介紹的基于 MySQL 5.5 版本的按行分發的策略是差不多的。不過，MySQL 官方的這個實現還是有很大的優勢：

writeset 是在主庫生成后直接寫入到 binlog 里面的，這樣在備庫執行的時候，不需要解析 binlog 內容（event 里的行數據），節省了很多計算量；

不需要把整個事務的 binlog 都掃一遍才能決定分發到哪個 worker，更省內存；

由于備庫的分發策略不依賴于 binlog 內容，所以 binlog 是 statement 格式也是可以的。

因此，MySQL 5.7.22 的并行復制策略在通用性上還是有保證的。

當然，對于“表上沒主鍵”和“外鍵約束”的場景，WRITESET 策略也是沒法并行的，也會暫時退化為單線程模型。

圖中，虛線箭頭表示的是主備關系，也就是 A 和 A’互為主備， 從庫 B、C、D 指向的是主庫 A。一主多從的設置，一般用于讀寫分離，主庫負責所有的寫入和一部分讀，其他的讀請求則由從庫分擔。

MySQL 主從，5 分鐘帶你掌握

MySQL 主從一直是面試常客，里面的知識點雖然基礎，但是能回答全的同學不多。

比如樓哥之前面試小米，就被問到過主從復制的原理，以及主從延遲的解決方案，因為回答的非常不錯，給面試官留下非常好的印象。你之前面試，有遇到過哪些 MySQL 主從的問題呢？

所謂 MySQL 主從，就是建立兩個完全一樣的數據庫，一個是主庫，一個是從庫， 主庫對外提供讀寫的操作，從庫對外提供讀的操作 ，下面是一主一從模式：

對于數據庫單機部署，在 4 核 8G 的機器上運行 MySQL 5.7 時，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當遇到一些活動時，查詢流量驟然，就需要進行主從分離。

大部分系統的訪問模型是讀多寫少，讀寫請求量的差距可能達到幾個數量級，所以我們可以通過一主多從的方式， 主庫只負責寫入和部分核心邏輯的查詢，多個從庫只負責查詢，提升查詢性能，降低主庫壓力。

MySQL 主從還能做到服務高可用，當主庫宕機時，從庫可以切成主庫，保證服務的高可用，然后主庫也可以做數據的容災備份。

整體場景總結如下：

MySQL 的主從復制是依賴于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進制形式保存在磁盤上二進制日志文件。

主從復制就是將 binlog 中的數據從主庫傳輸到從庫上，一般這個過程是異步的，即主庫上的操作不會等待 binlog 同步的完成。

詳細流程如下：

當主庫和從庫數據同步時，突然中斷怎么辦？因為主庫與從庫之間維持了一個長鏈接，主庫內部有一個線程，專門服務于從庫的這個長鏈接的。

對于下面的情況，假如主庫執行如下 SQL，其中 a 和 create_time 都是索引：

我們知道，數據選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來的數據一般是不一樣的。

所以就會存在這種情況：在 binlog = statement 格式時，主庫在執行這條 SQL 時，使用的是索引 a，而從庫在執行這條 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 格式。

有時候我們遇到從數據庫中獲取不到信息的詭異問題時，會糾結于代碼中是否有一些邏輯會把之前寫入的內容刪除，但是你又會發現，過了一段時間再去查詢時又可以讀到數據了，這基本上就是主從延遲在作怪。

主從延遲，其實就是“從庫回放” 完成的時間，與 “主庫寫 binlog” 完成時間的差值， 會導致從庫查詢的數據，和主庫的不一致 。

談到 MySQL 數據庫主從同步延遲原理，得從 MySQL 的主從復制原理說起：

總結一下主從延遲的主要原因 ：主從延遲主要是出現在 “relay log 回放” 這一步，當主庫的 TPS 并發較高，產生的 DDL 數量超過從庫一個 SQL 線程所能承受的范圍，那么延時就產生了，當然還有就是可能與從庫的大型 query 語句產生了鎖等待。

我們一般會把從庫落后的時間作為一個重點的數據庫指標做監控和報警，正常的時間是在毫秒級別，一旦落后的時間達到了秒級別就需要告警了。

解決該問題的方法，除了縮短主從延遲的時間，還有一些其它的方法，基本原理都是盡量不查詢從庫。

具體解決方案如下：

在實際應用場景中，對于一些非常核心的場景，比如庫存，支付訂單等，需要直接查詢從庫，其它非核心場景，就不要去查主庫了。

兩臺機器 A 和 B，A 為主庫，負責讀寫，B 為從庫，負責讀數據。

如果 A 庫發生故障，B 庫成為主庫負責讀寫，修復故障后，A 成為從庫，主庫 B 同步數據到從庫 A。

一臺主庫多臺從庫，A 為主庫，負責讀寫，B、C、D為從庫，負責讀數據。

如果 A 庫發生故障，B 庫成為主庫負責讀寫，C、D負責讀，修復故障后，A 也成為從庫，主庫 B 同步數據到從庫 A。

如何用mysql workbench做mysql主備

雙擊或右鍵打開MySQL Workbench，進入軟件主界面。

點擊new connection,會有個彈出框，讓我們填寫user(用戶名)，password(密碼)。

填寫完用戶名和密碼，點擊確定就會出現我們創建的數據庫工作空間，例如：local instance MySQL56。

雙擊local instance MySQL56，進入數據庫工作空間。

在左上方找到一個圓柱形帶加號的圖標，單擊該圖標，可以顯示出數據庫名讓我們填例如：baidu。

創建好數據庫，我們在左菜單欄找到baidu這個數據庫，雙擊該數據庫，可以看到下面有個tables,右鍵table，選擇create table，就能創建表了。

如何實現自動化配置mysql主備

如何實現自動化配置mysql主備

重新啟動MySQL服務

/etc/rc.d/init.d/mysql start

或用reboot命令重啟Linux

如果工作正常移動就成功了，否則對照前面的7步再檢查一下。

為了在其它電腦上能用root用戶登錄,需進行以下動作:

1、[email=mark@marklinux]mark@marklinux[/email] markmysql -h localhost -u root

//這樣應該可以進入MySQL服務器

2、mysqlGRANT ALL PRIVILEGES ON *.* TO [email='root'@'%']'root'@'%'[/email] WITH GRANT OPTION

//賦予任何主機訪問數據的權限

3、mysqlFLUSH PRIVILEGES

//修改生效

4、mysqlEXIT

//退出MySQL服務器

mysql怎么實現主從同步數據庫備份？

1.主服務器：

#Master start

log-bin="d:/log/mysql/mysql_log_bin"

server-id=1

　#Master end

2.從服務器：

#Slave start

log-bin="D:/log/mysql2/log-bin.log"

relay_log="D:/log/mysql2/relay-log-bin"

#從機id，區別于主機id

server-id=2

#主機ip，供從機連接主機用

#master-host=localhost

#主機端口

#master-port=3300

#剛才為從機復制主機數據新建的賬號

#master-user=slave

#剛才為從機復制主機數據新建的密碼

#master-password=654321

#重試間隔時間10秒

#master-connect-retry=10

#需要同步的數據庫

#replicate-do-db=test

#啟用從庫日志，這樣可以進行鏈式復制

log-slave-updates

#從庫是否只讀，0表示可讀寫，1表示只讀

read-only=1

#只復制某個表

#replicate-do-table=tablename

#只復制某些表（可用匹配符）

#replicate-wild-do-table=tablename%

#只復制某個庫

#replicate-do-db=dbname

#不復制某個表

#replicate-ignore-table=tablename

#不復制某些表

#replicate-wild-ignore-table=tablename%

#不復制某個庫

#replicate-ignore-db=dbname

#Slave end

3.對從服務器制定主服務器使用CHANGE MASTER 語句

注意：1.一定要在主服務器上創建一個可以執行replication的用戶

2.該用戶名在從服務器上可遠程登錄到主服務器。

3.開啟MySQL的log-bin日志功能

網頁名稱：mysql主備怎么實現,mysql主備方案
標題URL：http://vcdvsql.cn/article6/dsiipig.html

成都網站建設公司_創新互聯，為您提供外貿建站、網站排名、網站設計、域名注冊、動態網站、網站改版

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯