原文鏈接地址：http://www.cnblogs.com/lyhabc/p/3888702.html
最近把大學時候的ORACLE教程書本翻出來看，真的是感觸良多
以前在學校的時候，每次ORACLE測驗和考試都是不合格的，期末的時候靠補考才勉強過關
大家看到下圖的封面應該知道大學教我們ORACLE課程的老師，沒錯，他就是李愛武老師
大家可能對李愛武老師不太熟悉，在ORACLE領域，大家第一時間肯定會想到“蓋國強”
還記得前段時間某個媒體說“蓋國強”是中國第一DBA，但是我在百度裡面搜索“中國第一DBA”並沒有出現“蓋國強”三個字o(∩_∩)o
李愛武老師可能會有一些人認識，他寫了幾本數據庫方面的書，以SQLSERVER和ORACLE為主
老師的實力是毋容置疑的，老師上課的風格是比較凶的那種，不過老師他很細心，會把ORACLE裡面的知識點講透
因為比較凶，所以很多時候不是很想上他的課，有時候會選擇逃課，但是想不到多年後自己會做了DBA，會研究數據庫
雖然未到教師節，但是還是要感謝李愛武老師和大學裡教我計算機知識的其他老師，感謝
不扯了，馬上開始今天的內容。。。
的
這一篇主要介紹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
View Code
將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 中未完成的一個事務，對實際數據沒有任何實質性影響。從以往經驗
和相關測試來看，對於高並發事務的系統來說，“sync_binlog”設置為 0 和設置為 1 的系統寫入性能差
距可能高達 5 倍甚至更多。
如果master主機上的max_allowed_packet比較大，但是從機上沒有配置該值的話，該參數還是使用默認值1MB
此時很有可能導致同步失敗，建議主從兩台機器都設為5MB比較合適
總結
本文簡單的闡述了MYSQL的復制方面的內容，MYSQL復制是比較重要的技術
文本的主從切換使用手工的方式，當然在真實生產環境一般使用自動切換腳本和軟件工具去做自動主從切換，這裡不做介紹了
希望這篇文章對大家有幫助
