程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> MySQL優化之——復制

MySQL優化之——復制

編輯：MySQL綜合教程

MySQL優化之——復制

MYSQL 從3.25.15版本開始提供數據庫復制功能（replication）。mysql復制是指從一個mysql主服務器（MASTER）將數據復制到另一台或多台mysql從服務器（SLAVE）的過程，將主數據庫的DDL和DML操作通過二進制日志傳到復制服務器上，然後在從服務器上對這些日志重新執行，從而使從服務器的數據保持同步。在mysql中，復制操作是異步進行的，slave服務器不需要持續的保持連接接收master服務器的數據mysql支持一台主服務器同時向多台從服務器進行復制操作，從服務器同時可以作為其他從服務器的主服務器，如果mysql主服務器訪問量大，可以通過復制數據，然後在從服務器上進行查詢操作，從而降低主服務器的訪問壓力（讀寫分離），同時從服務器作為主服務器的備份，可以避免主服務器因為故障數據丟失的問題。

mysql數據庫復制操作大致可以分為三個步驟

1主服務器將數據的改變記錄到二進制日志（binlog）中。

2、從服務器將主服務器的binary log events復制到他的中繼日志（relay log）中。

3、從服務器做中繼日志中的事件，將數據的改變與從服務器保持同步。

首先，主服務器會記錄二進制日志，每個事務更新完畢數據之前，主服務器將這些操作的信息記錄在二進制日志裡面，在事件寫入

二進制日志完成後，主服務器通知存儲引擎提交事務。SLAVE上面的I/O進程連接上MASTER，並發出日志請求，MASTER接收到來自SLAVE的I/O進程的請求後，通過負責復制的I/O進程根據請求信息讀取指定日志位置之後的日志信息，返回給SLAVE的I/O進程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息已經到MASTER端的binlog文件的名稱以及binlog的位置SLAVE的I/O進程接收到信息後，將接收到的日志內容依次添加到SLAVE端的relay-log文件的最末端，並將讀取到的MASTER端的binlog文件名和位置記錄到master-Info文件中。SLAVE的SQL進程檢測到relay-log中新增了內容後，會馬上解析relay-log的內容成為在master端真實執行時候的那些可執行內容，並在自身執行mysql復制環境，90%以上都是一個master帶一個或者多個slave的架構模式。如果master和slave壓力不是太大的話，異步復制的延時一般都很少。尤其是slave端的復制方式改成兩個進程處理之後，更是減少了slave端的延時

提示：對於數據實時性要求不是特別嚴格的應用，只需要通過廉價的電腦服務器來擴展slave的數量，將讀壓力分散到多台slave的機器上面

即可解決數據庫端的讀壓力瓶頸。這在很大程度上解決了目前很多中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決

數據庫瓶頸問題

Windows環境下的mysql主從復制

復制前的准備工作

在Windows環境下，如果想實現主從復制需要准備的操作環境

角色 ip 端口操作系統 mysql版本

master 192.168.1.100 3306 Windows7 5.5.20

slave 192.168.1.102 3306 Windows8 5.5.20

Windows環境下實現主從復制

准備好兩台安裝mysql5.6的計算機，即可實現兩台mysql服務器主從復制備份操作。

具體操作步驟如下：

1、在Windows下安裝好兩台mysql服務器，配置好兩台主機的ip地址，實現兩台計算機可以網絡連通

2、配置master的相關配置信息，在master主機上開啟binlog日志，首先，看下datadir的具體路徑

show variables  LIKE '%datadir%'

3、此時需要打開在D:\Program Files (x86)\MySQL\MySQL Server 5.5路徑下的配置文件my.ini，添加如下代碼，開啟binlog功能

[mysqld]
log-bin="D:/MYSQLDataBase/binlog"
expire_logs_days=10
max_binlog_size=100M

提示：此事我們需要在D盤下面創建MYSQLDATABASE文件夾，binlog日志記錄在該文件夾裡面，該配置文件中的其他參數如下所示

expire_logs_days：表示二進制日志文件刪除的天數

max_binlog_size：表示二進制日志文件最大的大小

4、登錄mysql後，可以執行show VARIABLES LIKE '%log_bin%'命令來測試下log_bin是否成功開啟

show VARIABLES LIKE '%log_bin%';

如果log_bin參數是ON的話，那麼表示二進制日志文件已經成功開啟，如果為OFF的話，那麼表示二進制日志文件開啟失敗

5、在master上配置復制所需要的賬戶，這裡創建一個repl的用戶，%表示任何遠程地址的repl用戶都可以連接master主機

GRANT replication slave ON *.*TO repl@'%' IDENTIFIED BY '123';
flush privileges;

6、在my.ini配置文件裡配置master主機的相關信息

[mysqld]
log-bin="D:/MYSQLDataBase/binlog"
expire_logs_days=10
max_binlog_size=100M

server-id=1
binlog-do-db=test
binlog-ignore-db=mysql

這些配置語句的含義

server-id：表示服務器表示id號，master和slave主機的server-id不能一樣

binlog-do-db：表示需要復制的數據庫，這裡以test庫為例

binlog-ignore-db：表示不需要復制的數據庫

7、重啟master主機上的mysql服務，然後輸入show master status命令查詢master主機的信息

8、將master主機的數據備份出來，然後導入到slave主機中去，具體執行語句如下

mysqldump -u root -p -h 127.0.0.1 test >D:\TEST.TXT

TEST庫裡面的表和數據

innodb_monitor表是沒有數據的

dump出來的txt文件內容

-- MySQL dump 10.13  Distrib 5.5.20, for Win32 (x86)
--
-- Host: 127.0.0.1    Database: test
-- ------------------------------------------------------
-- Server version    5.5.20-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `book`
--

DROP TABLE IF EXISTS `book`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `book` (
  `bookid` int(11) NOT NULL,
  `bookname` varchar(255) NOT NULL,
  `authors` varchar(255) NOT NULL,
  `info` varchar(255) DEFAULT NULL,
  `comment` varchar(255) DEFAULT NULL,
  `year_publication` year(4) NOT NULL,
  KEY `year_publication` (`year_publication`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `book`
--

LOCK TABLES `book` WRITE;
/*!40000 ALTER TABLE `book` DISABLE KEYS */;
INSERT INTO `book` VALUES (12,'dajiahao','NIHAO','??','henhao',1990);
/*!40000 ALTER TABLE `book` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `innodb_monitor`
--

DROP TABLE IF EXISTS `innodb_monitor`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `innodb_monitor` (
  `a` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `innodb_monitor`
--

LOCK TABLES `innodb_monitor` WRITE;
/*!40000 ALTER TABLE `innodb_monitor` DISABLE KEYS */;
/*!40000 ALTER TABLE `innodb_monitor` ENABLE KEYS */;
UNLOCK TABLES;


/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2014-08-05 22:36:17

將D:\TEST.TXT文件復制到slave機器上，然後執行如下操作

在命令行登錄mysql，然後 USE TEST;

記得一定要USE TEST，切換數據庫上下文，否則會報錯：NO DATABASE SELECTED 的錯誤信息

然後執行source命令導入TEXT.txt文件的內容

可以看到，數據已經導入到slave上面了

9、配置slave機器（192.168.1.102）的my.ini配置文件

具體配置信息如下

[mysql]

default-character-set=utf8
log_bin="C:/MYSQLLOG/binlog"
expire_logs_days=10
max_binlog_size=100M

[mysqld]
server-id=2

提示：配置slave主機my.ini文件的時候，需要將server-id=2寫到[mysqld]後面

另外如果配置文件中還有log_bin的配置，可以將他注釋掉，如下所示

#Binary Logging
#log-bin
#log_bin="xxx"

10、重啟slave主機（192.168.1.102）的mysql服務，在slave主機（192.168.1.102）的mysql中執行如下命令

關閉slave服務

stop slave;

11、設置slave從機實現復制相關的信息，命令如下

change master to
master_host='192.168.1.100',
master_user='repl',
master_password='123',
master_log_file='binlog。000004',
master_log_pos=107;

Command(s) completed successfully.

各個參數所代表的具體含義如下：

master_host：表示實現復制的主機ip地址

master_user：表示實現復制的登錄遠程主機的用戶

master_password：表示實現復制的登錄遠程主機的密碼

master_log_file：表示實現復制的binlog日志文件

master_log_pos：表示實現復制的binlog日志文件的偏移量

12、繼續在從機執行操作，顯示slave從機的狀況，如下所示

start slave;

Command(s) completed successfully.

mysql> SHOW SLAVE STATUS \G; *************************** 1. row *************************** Slave_IO_State: Master_Host: 192.168.1.100 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog銆?00004 Read_Master_Log_Pos: 107 Relay_Log_File: Steven-PC-relay-bin.000002 Relay_Log_Pos: 4 Relay_Master_Log_File: binlog銆?00004 Slave_IO_Running: No Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 107 Relay_Log_Space: 107 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading dat a from binary log: 'Could not find first log file name in binary log index file' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 1 row in set (0.00 sec) ERROR: No query specified

在上述執行show slave status \G命令中很顯然存在一些問題，問題如下

 Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading dat
a from binary log: 'Could not find first log file name in binary log index file'

下面的步驟可以解決問題，具體步驟如下

1、重啟master（192.168.1.100）主機的mysql服務，執行show master status \G命令

記下File和Position的值，後面slave主機會用到，命令執行如下

SHOW MASTER STATUS;

2、在slave（192.168.1.102）主機上重新設置信息，命令執行如下

stop slave;

change master to
master_log_file='binlog.000005',
master_log_pos=107;

start slave;

mysql> SHOW SLAVE STATUS \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.100
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000005
          Read_Master_Log_Pos: 107
               Relay_Log_File: Steven-PC-relay-bin.000002
                Relay_Log_Pos: 250
        Relay_Master_Log_File: binlog.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 107
              Relay_Log_Space: 410
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
1 row in set (0.00 sec)

ERROR:
No query specified

這次正常了，實際上剛才有兩個地方是錯誤的

第一個：在從機的my.ini裡面

[mysql]
default-character-set=utf8
#log_bin="C:/MYSQLLOG/binlog"
#expire_logs_days=10
#max_binlog_size=100M

在從機的my.ini裡面的mysql配置節下面配置了binlog，實際上這樣做是錯誤的，要配置binlog需要在[mysqld]配置節下

第二個：第一次配置從機的同步的時候本人寫錯了標點符號，.號寫成。號

master_log_file='binlog。000004',

這時候，我們可以在從機上面執行show processlist來查詢從服務器的進程狀態

mysql> show processlist \G
*************************** 1. row ***************************
     Id: 4
   User: root
   Host: localhost:60968
     db: information_schema
Command: Sleep
   Time: 3613
  State:
   Info: NULL
*************************** 2. row ***************************
     Id: 5
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 3613
  State: Waiting for master to send event
   Info: NULL
*************************** 3. row ***************************
     Id: 6
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 2769
  State: Slave has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL
*************************** 4. row ***************************
     Id: 7
   User: root
   Host: localhost:61007
     db: NULL
Command: Query
   Time: 0
  State: NULL
   Info: show processlist
4 rows in set (0.04 sec)

結果表明slave已經連接上master，開始接收並執行日志

relay-log.info文件裡面的內容

.\Steven-PC-relay-bin.000002
250
binlog.000005
107
7

relay-log.info文件裡面記錄了slave端的relaylog的當前文件名和位置，還有master端的binlog文件名和位置

Windows環境下主從復制測試

1、在master端的mysql環境下，執行下面命令

use test;
create table rep_test(data integer);

insert into rep_test values(2);

2、在slave端的mysql環境下，查看主機剛才添加的表和數據是否成功同步到從機上

use test;

show tables;

select * FROM REP_TEST;

測試表明，數據已經成功地同步到slave上，實驗中只是用到了主從同步，在實際生產環境中MYSQL架構可能會用到一主多從的架構

MYSQL主要復制啟動選項

（1）log-slave-updates

log-slave-updates這個參數主要用來配置從服務器的更新是否寫入二進制日志，該選項默認是不打開的，如果這個

從服務器同時也作為其他服務器的主服務器，搭建一個鏈式的復制，那麼就需要開啟這個選項，這樣從服務器才能獲取他

的二進制日志進行同步操作

（2）master-connect-retry

master-connect-retry這個參數用來設置和主服務器連接丟失的時候進行重試的時間間隔，默認是60秒

（3）read-only

read-only是用來限制普通用戶對從數據庫的更新操作，以確保從數據庫的安全性，不過如果是超級用戶依然可以對

從數據庫進行更新操作。如果主數據庫創建了一個普通用戶，在默認情況下，該用戶是可以更新從數據庫的數據的，如果

使用read-only選項啟動從數據庫以後，用戶對從數據庫進行更新時會提示錯誤

在Linux下啟動mysql例子

[root@localhost~]#mysqld_safe -read-only

（4）slave-skip-errors

在復制過程中，從服務器可以會執行BINLOG中的錯誤SQL語句，此時如果不忽略錯誤，從服務器會停止復制進程，等待用戶處理錯誤。

這種錯誤如果不能及時發現，將會對應用或者備份產生影響。slave-skip-errors的作用就是用來定義復制過程中從服務器可以自動

跳過的錯誤號，設置該參數後，mysql會自動跳過所配置的一系列錯誤，直接執行後面的SQL語句，該參數可以定義多個錯誤號，如果

設置成all，則表示跳過所有的錯誤，在my.ini或者my.cnf裡配置如下

slave-skip-errors=1007,1051,1062

如果從數據庫主要作為主庫的備份，那麼就不應該使用這個啟動參數，因為一旦設置不當很可能造成主從庫的數據不同步。

如果從庫僅僅是為了分擔主庫的查詢壓力，並且對數據的完整性要求不高，那麼這個選項可以減輕DBA維護從庫的工作量

查看slave的復制進度

很多情況下，用戶都想知道從服務器復制的進度，從而判斷從服務器上復制數據的完整性，同時判斷是否需要手工來做

主從同步工作。

事實上，用戶可以通過show processlist列表中的Slave_SQL_Running線程的Time值得到，他記錄了從服務器當前執行的SQL時間戳

和系統時間之間的差距，例如下面的例子

  Id: 6
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 2769
  State: Slave has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL

Time時間說明從服務器最後執行的更新操作大概是主服務器2769秒前的更新操作

日常管理和維護

復制配置完成後，DBA需要進行日常的監控和管理維護工作，以便能夠及時發現問題和解決問題

以保證主從數據庫能夠正常工作。

1、了解服務器的狀態

一般使用show slave status命令來檢查從服務器

在查看服務器信息中，首先要查看下面的兩個進程是否為YES。

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Slave_IO_Running表明此進程是否能夠由從服務器到主服務器上正確地讀取binlog日志，並寫入到從服務器的中繼日志中

Slave_SQL_Running表明此進程能否讀取並執行中繼日志中的binlog信息

2、服務器復制出錯原因

問題一：出現“log event entry exceeded max_allowed_pack”錯誤

如果在應用中使用大的BLOB列或CLOB列或者長字符串，那麼在從服務器上回復時，可能會出現

“log event entry exceeded max_allowed_pack”的錯誤，這是因為含有達文本的記錄無法通過網絡進行傳輸而導致的

解決方法是在主服務器和從服務器上添加max_allowed_packet參數，該參數默認設置為1MB

show variables LIKE '%max_all%'

Variable_name      Value   
------------------ ------- 
max_allowed_packet 1048576 

(1 row(s) affected)

set @@global.max_allowed_packet=16777216;

同時在my.ini或my.cnf文件裡設置max_allowed_packet=16M，數據庫重啟之後該參數將有效

問題二：多主復制時的自增長變量沖突問題

大多數情況下使用一台主服務器對一台或者多台從服務器，但是在某些情況下可能會存在多個服務器配置為復制主服務器，

使用auto_increment時應采取特殊步驟以防止鍵值沖突，否則插入時多個主服務器會試圖使用相同的auto_increment值

服務器變量auto_increment_increment和auto_increment_offset可以協調多主服務器復制auto_increment列

在多主服務器復制到從服務器的過程中會發生主鍵沖突問題，可以將不同的主服務器的這兩個參數重新進行設置，將A庫

上設置auto_increment_increment=1，auto_increment_offset=1，此時B庫上設置

auto_increment_increment=1，auto_increment_offset=0

提示：一般不建議使用雙主或多主，因為這樣會帶來意想不到的沖突狀況，就像SQLSERVER的對等復制，雖然有很多沖突檢測措施

但是有時候沖突是不可預料的，出現沖突DBA要排查，維護成本較高，我們生產環境裡是沒有使用雙主和多主，主要使用的是一主多從或一主一從

切換主從服務器

在實際生產環境，如果主機上的主庫發生故障，需要將從機上的從庫切換成主庫，同時需要修改服務器C的配置文件，使程序連接到從機

下面介紹主從切換的步驟

1、首先要確保所有的從庫都已經執行了relay log中的全部更新，看從庫的狀態是否是Has read all relay log，是否更新都已經執行完成

在從庫上執行下面命令

STOP SLAVE IO_THREAD;

Command(s) completed successfully.

mysql> show processlist \G
*************************** 1. row ***************************
     Id: 4
   User: root
   Host: localhost:60968
     db: test
Command: Sleep
   Time: 45
  State:
   Info: NULL
*************************** 2. row ***************************
     Id: 6
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 3949
  State: Slave has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL
*************************** 3. row ***************************
     Id: 7
   User: root
   Host: localhost:61007
     db: NULL
Command: Query
   Time: 0
  State: NULL
   Info: show processlist
3 rows in set (0.00 sec)

2、在從庫上停止slave服務，然後執行reset master重置成為主庫

STOP SLAVE;

Command(s) completed successfully.

RESET MASTER;
Command(s) completed successfully.

注意：如果從庫上並未開binlog，那麼在執行reset master的時候會報錯：ERROR 1186(HY000):BINLOG CLOSED ,CANNOT RESET MASTER

在切換之後，在從庫的數據目錄會多出master.info文件

master.info文件裡的內容

18
binlog.000005
393
192.168.1.100
repl
123
3306
60
0

0
1800.000

0
0

基本上記錄了主庫的復制用戶、密碼和binlog文件名和位置等

3、在從庫B（192.168.1.102）上添加具有replication權限的用戶repl，查詢主庫狀態，命令如下

GRANT REPLICATION SLAVE ON *.*TO 'repl'@'localhost' identified by '123';

show master status;

4、修改主服務器的my.ini文件裡的server-id為1，從服務器的server-id為2

5、在原來的主庫（192.168.1.100）上配置復制參數

change master TO
master_host='192.168.1.102',
master_user='repl',
master_password='123',
master_port=3306,
master_log_file='on.000004',
master_log_pos=107;

6、在從庫（192.168.1.100）上執行show slave status命令查看從庫是否啟動成功

START SLAVE;

mysql> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.102
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: on.000004
          Read_Master_Log_Pos: 107
               Relay_Log_File: joe-relay-bin.000006
                Relay_Log_Pos: 246
        Relay_Master_Log_File: on.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 107
              Relay_Log_Space: 436
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
1 row in set (0.00 sec)

ERROR:
No query specified

注意：如果在主庫上面（192.168.1.102）的復制用戶repl沒有允許遠程主機從庫的訪問，那麼在執行show slave status的時候就會報錯

 Last_IO_Errno: 1130
 Last_IO_Error: error connecting to master '[email protected]:3360  retries: 8640006' - retry-time: 60  retries: 86400

這時候，只需要在主庫（192.168.1.102）上面執行下面語句即可

use mysql;
select * from user where user='repl';
update user set host = '%' where user ='repl';
flush privileges;

7、在主庫和從庫上面是否成功設置復制功能，首先在主庫（192.168.1.102）上查看test庫中的表

use test;
show tables;

查詢從庫中（192.168.1.100）test庫裡表的情況

use test;
show tables;

跟主庫一樣

8、在主庫（192.168.1.102）中增加表rep_t ，並插入數據

create table rep_t(data int);

insert into rep_t values(1);

9、在從庫（192.168.1.100）上查詢表是否已經創建並復制數據到從庫中

USE test;

show variables like '%server%';

show tables;

SELECT * FROM rep_t;

至此，主從庫成功切換

如果主機和從機server-id一樣如何解決

通常情況下，master和slave的server-id是不會一樣的，如果一樣的話會出現報錯

出現這種情況，用戶可以使用如下命令來查看服務器的server-id，然後手動進行修改，如下所示

show variables like '%server_id%';

Variable_name Value 
------------- ----- 
server_id     2     

(1 row(s) affected)

SET global server_id=1

修改完成後，執行slave start命令，查詢slave主機的狀態，查看問題可否解決

從機狀態顯示Last_IO_Error錯誤代碼為2013的原因

有時候會遇到這樣的情況，在執行show slave status \G 命令中 Slave_IO_Running和Slave_SQL_Running的值都是YES

但是Last_IO_Error發生2013錯誤

發生這種問題主要原因是網絡問題，首先要檢查下master主機創建的用戶是否授予遠程連接的權限

GRANT replication slave ON *.*TO repl@'%' IDENTIFIED BY '123';

這裡%表示任何的repl用戶都可以訪問master主機，另外需要查看是否有防火牆設置和網絡的其他故障

MYSQL復制不同步的原因

mysql replication（復制）采用binlog進行網絡傳輸，所以網絡延時是產生mysql主從不同步的主要原因，這會給我們進行讀寫分離帶來

一定困難為了避免這種情況，在配置服務器的時候推薦使用INNODB存儲引擎的表，在主機上可以設置sync_binlog

下面內容摘抄自《MYSQL行調優和架構設計》

“sync_binlog”：這個參數是對於 MySQL 系統來說是至關重要的，他不僅影響到 Binlog 對 MySQL 所

帶來的性能損耗，而且還影響到 MySQL 中數據的完整性。對於“sync_binlog”參數的各種設置的說明如

下：

● sync_binlog=0，當事務提交之後，MySQL 不做 fsync 之類的磁盤同步指令刷新 binlog_cache 中

的信息到磁盤，而讓 Filesystem 自行決定什麼時候來做同步，或者 cache 滿了之後才同步到磁

盤。

● sync_binlog=n，當每進行 n 次事務提交之後，MySQL 將進行一次 fsync 之類的磁盤同步指令來

將 binlog_cache 中的數據強制寫入磁盤。

在 MySQL 中系統默認的設置是 sync_binlog=0，也就是不做任何強制性的磁盤刷新指令，這時候的性

能是最好的，但是風險也是最大的。因為一旦系統 Crash，在 binlog_cache 中的所有 binlog 信息都會被

丟失。而當設置為“1”的時候，是最安全但是性能損耗最大的設置。因為當設置為 1 的時候，即使系統

Crash，也最多丟失 binlog_cache 中未完成的一個事務，對實際數據沒有任何實質性影響。從以往經驗