MySQL的主從復(fù)制步驟詳解及常見錯(cuò)誤解決方法
mysql主從復(fù)制(replication同步)現(xiàn)在企業(yè)用的比較多,也很成熟.它有以下優(yōu)點(diǎn):
1.降低主服務(wù)器壓力,可在從庫上執(zhí)行查詢工作.
2.在從庫上進(jìn)行備份,避免影響主服務(wù)器服務(wù).
3.當(dāng)主庫出現(xiàn)問題時(shí),可以切換到從庫上.
不過,用它做備份時(shí)就會(huì)也有弊端,如果主庫有誤操作的話,從庫也會(huì)收到命令.
下面直接進(jìn)入操作.這里使用的是debian5操作系統(tǒng),mysql5.0,默認(rèn)引擎innodb
10.1.1.45 主庫
10.1.1.43 從庫
1.設(shè)置主庫
1)修改主庫my.cnf,這里主要是server-id一定主從不要設(shè)置成一樣的.打開binlog日志
log-bin = /opt/log.bin/45 server-id = 45
mysql> grant REPLICATION SLAVE ON *.* TO 'repl'@'10.1.1.43' IDENTIFIED BY 'replpass';
注意:mysql的權(quán)限系統(tǒng)在實(shí)現(xiàn)上比較簡(jiǎn)單,相關(guān)權(quán)限信息主要存儲(chǔ)在幾個(gè)系統(tǒng)表中:mysql.user,mysql.db,mysql.host,mysql.table_priv,mysql.columm_priv.由于權(quán)限信息的數(shù)據(jù)量比較小,訪問又非常頻繁,所以mysql在啟動(dòng)的時(shí)候,就會(huì)將所有的權(quán)限信息都加載到內(nèi)存中,并保存在幾個(gè)特定的結(jié)構(gòu)里.這就使得每次手動(dòng)修改了相關(guān)權(quán)限表之后,都需要執(zhí)行flush privileges,通知mysql重新加載mysql的權(quán)限信息.當(dāng)然,如果通過grants,revoke或drop user 命令來修改相關(guān)權(quán)限,則不需要手動(dòng)執(zhí)行flush privileges命令.
3)在主服務(wù)器上導(dǎo)出數(shù)據(jù)庫當(dāng)時(shí)的快照,傳給從庫上.
root@10.1.1.45:mysql# mysqldump -uroot -p --single-transaction --flush-logs --master-data --all-databases > all.sql
--single-transaction:這個(gè)選項(xiàng)能夠讓innoDB和Falcon數(shù)據(jù)表在備份過程中保持不變.這一做法的關(guān)鍵在于它是在同一個(gè)事務(wù)里來導(dǎo)入各有關(guān)數(shù)據(jù)表的.mysqldump使用repeatable read事務(wù)隔離層來生成一份穩(wěn)定一致的轉(zhuǎn)儲(chǔ)文件,同時(shí)不會(huì)阻塞其他客戶(對(duì)于非事務(wù)性表,轉(zhuǎn)儲(chǔ)過程可能有變化),它不能與--lock-all-tables選項(xiàng)一起使用.
--flush-logs:在導(dǎo)出工作開始之前先清空mysql服務(wù)器的日志文件.這樣更容易恢復(fù)操作,知道在檢查點(diǎn)時(shí)間之后創(chuàng)建的二進(jìn)制日志文件是在備份給定數(shù)據(jù)庫之后完成的.結(jié)合使用--lock-all-tables或--master-data,只有在所有數(shù)據(jù)表都鎖定之后才清除日志.這個(gè)選項(xiàng)需要具備reload權(quán)限.
--master-data:使用后mysqldump會(huì)在dump文件中產(chǎn)生changer master to命令,里面記錄了dump時(shí)刻所對(duì)應(yīng)的詳細(xì)的log position信息.
root@10.1.1.45:mysql# sed -n '1,40p' all.sql -- MySQL dump 10.11 -- -- Host: localhost Database: -- ------------------------------------------------------ -- Server version 5.0.51a-24+lenny1-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 */; -- -- Position to start replication or point-in-time recovery from -- CHANGE MASTER TO MASTER_LOG_FILE='45.000064', MASTER_LOG_POS=98; -- -- Current Database: `bbs` -- CREATE DATABASE /*!32312 IF NOT EXISTS*/ `bbs` /*!40100 DEFAULT CHARACTER SET latin1 */; USE `bbs`; -- -- Table structure for table `davehe` -- DROP TABLE IF EXISTS `davehe`; SET @saved_cs_client = @@character_set_client; SET character_set_client = utf8; CREATE TABLE `davehe` (
2.設(shè)置從庫
1).修改從庫my.cnf
server-id = 43 #主從可1對(duì)多 從各id不能相同
2)將主庫的快照灌入從庫
root@10.1.1.43:tmp# cat all.sql | mysql -uroot -p
3)在從庫上設(shè)置同步.查看從庫狀態(tài).
mysql> change master to master_host='10.1.1.45', master_user='repl',master_password='replpass',master_log_file='45.000064',master_log_pos=98;
Query OK, 0 rows affected (0.01 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.1.1.45
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 45.000064
Read_Master_Log_Pos: 98
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 228
Relay_Master_Log_File: 45.000064
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: 98
Relay_Log_Space: 228
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
1 row in set (0.00 sec)
ERROR:
No query specified
測(cè)試OK
當(dāng)然這只是最簡(jiǎn)單的配置
還有很多參數(shù)可根據(jù)環(huán)境需求變化.
比如
- replicate-do-db=test 過濾拉主日志到從只需要這個(gè)庫和下面的表
- replicate-wild-do-table=test.dave
- replicate-wild-do-table=test.davehe
mysql數(shù)據(jù)庫同步跳過臨時(shí)錯(cuò)誤
stop slave; set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; (事務(wù)類型,可能需要執(zhí)行幾次) start slave; stop slave IO_THREAD //此線程把master段的日志寫到本地 start slave IO_THREAD stop slave SQL_THREAD //此線程把寫到本地的日志應(yīng)用于數(shù)據(jù)庫 start slave SQL_THREAD
Slave_IO_Running: No錯(cuò)誤
由于主庫的主機(jī)192.168.1.1宕機(jī),再次啟來后,從庫192.168.71.1連接主庫發(fā)現(xiàn)報(bào)錯(cuò). Slave_IO_Running: No
root@192.168.71.1:~# mysql -uroot -p --socket=/opt/mysql/3399/3399.sock
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 452723
Server version: 5.0.51a-24+lenny2 (Debian)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.1.1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 99.000302
Read_Master_Log_Pos: 165112917
Relay_Log_File: 3399-relay-bin.000013
Relay_Log_Pos: 165113047
Relay_Master_Log_File: 99.000302
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB: mysql
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: 165112917
Relay_Log_Space: 165113047
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
1 row in set (0.00 sec)
查看錯(cuò)誤日志
mysql@192.168.71.1:/opt/mysql/3399$ cat 192.168.71.1.err 140115 1:51:01 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 140115 1:51:01 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log 140115 1:51:01 [Note] Slave I/O thread exiting, read up to log '99.000302', position 165112917
根據(jù)錯(cuò)誤位置,查找主庫上log ‘99.000302' 對(duì)應(yīng)的位置 165112917
root@192.168.1.1:mysql.bin# mysqlbinlog 99.000302 > /tmp/test root@192.168.1.1:mysql# tail -n 10 /tmp/test #140115 0:50:25 server id 1176 end_log_pos 165111351 Query thread_id=111 exec_time=0 error_code=0 SET TIMESTAMP=1389718225/*!*/; INSERT INTO user_info_db_86.region_info_table_56 (userid, region, gameflag) VALUES (563625686, 0, 2) ON DUPLICATE KEY UPDATE gameflag = (gameflag | 2)/*!*/; # at 165111351 #140115 0:50:25 server id 1176 end_log_pos 165111378 Xid = 17877752 COMMIT/*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
結(jié)果發(fā)現(xiàn)主庫上位置最后是165111351 比165112917要小. 也就是從庫同步找的位置比主庫要大,故同步不成功
為什么會(huì)這樣,這是因?yàn)檫@個(gè)在sync_binlog=0的情況,很容易出現(xiàn)。
sync_binlog=0,當(dāng)事務(wù)提交之后,MySQL不做fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤,而讓系統(tǒng)自行決定什么時(shí)候來做同步,或者cache滿了之后才同步到磁盤。
sync_binlog=n,當(dāng)每進(jìn)行n次事務(wù)提交之后,MySQL將進(jìn)行一次fsync之類的磁盤同步指令來將binlog_cache中的數(shù)據(jù)強(qiáng)制寫入磁盤。
在MySQL中系統(tǒng)默認(rèn)的設(shè)置是sync_binlog=0,也就是不做任何強(qiáng)制性的磁盤刷新指令,這時(shí)候的性能是最好的,但是風(fēng)險(xiǎn)也是最大的。因?yàn)橐坏┫到y(tǒng)Crash,在binlog_cache中的所有binlog信息都會(huì)被丟失。而當(dāng)設(shè)置為“1”的時(shí)候,是最安全但是性能損耗最大的設(shè)置。因?yàn)楫?dāng)設(shè)置為1的時(shí)候,即使系統(tǒng)Crash,也最多丟失binlog_cache中未完成的一個(gè)事務(wù),對(duì)實(shí)際數(shù)據(jù)沒有任何實(shí)質(zhì)性影響。從以往經(jīng)驗(yàn)和相關(guān)測(cè)試來看,對(duì)于高并發(fā)事務(wù)的系統(tǒng)來說,“sync_binlog”設(shè)置為0和設(shè)置為1的系統(tǒng)寫入性能差距可能高達(dá)5倍甚至更多。
這里由于mysql是默認(rèn)配置所以該報(bào)錯(cuò)原因是: sync_binlog=0時(shí) ,master binlog文件的flush log buffer(這個(gè)buffer是由于binlog文件的os buffer) 到disk是依賴于OS本身的,但Slave IO 線程在讀取master dump 線程的位置,一般是直接讀取log buffer的,這個(gè)位置,可能遠(yuǎn)遠(yuǎn)大于binlog文件實(shí)際大小。 所以當(dāng)主機(jī)宕機(jī)后,binlog buffer未刷盤,當(dāng)Master主機(jī)再次啟動(dòng)后,此時(shí)從庫的binlog pos 165112917 已經(jīng)比實(shí)際的binlog位置大小165111351 還大了。
解決方法:
直接做change master to到當(dāng)下一個(gè)binlog。
CHANGE MASTER TO MASTER_HOST='192.168.1.1', MASTER_USER='repl', MASTER_PASSWORD='replpass', MASTER_PORT=3306, MASTER_LOG_FILE='99.000303', MASTER_LOG_POS=98;
相關(guān)文章
mysql提示got timeout reading communication packets的解決方法
今天發(fā)現(xiàn)mysql錯(cuò)誤日志中出現(xiàn)got timeout reading communication packets,一般情況因?yàn)椴糠猪撁嫔捎袉栴}導(dǎo)致,這里簡(jiǎn)單分享一下解決方法2019-05-05
MySQL安裝出現(xiàn)The?configuration?for?MySQL?Server?8.0.28?has
這篇文章主要給大家介紹了MySQL安裝出現(xiàn)The?configuration?for?MySQL?Server?8.0.28?has?failed.?You?can...錯(cuò)誤的解決辦法,文中通過圖文介紹的非常詳細(xì),需要的朋友可以參考下2023-09-09
mysql之查詢兩個(gè)時(shí)間段是否有交集的情況
這篇文章主要介紹了mysql之查詢兩個(gè)時(shí)間段是否有交集的情況,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-08-08
Mysql 5.7.18 利用MySQL proxies_priv實(shí)現(xiàn)類似用戶組管理
這篇文章主要為大家詳細(xì)介紹了Mysql 5.7.18利用MySQL proxies_priv實(shí)現(xiàn)類似用戶組管理,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-07-07
記一次MySQL Slave庫恢復(fù)實(shí)戰(zhàn)記錄
這篇文章主要介紹了記一次MySQL Slave庫恢復(fù)實(shí)戰(zhàn)記錄,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-07-07
Mysql使用索引實(shí)現(xiàn)查詢優(yōu)化
索引的目的在于提高查詢效率,本文給大家介紹Mysql使用索引實(shí)現(xiàn)查詢優(yōu)化技巧,涉及到索引的優(yōu)點(diǎn)等方面的知識(shí)點(diǎn),非常不錯(cuò),具有參考借鑒價(jià)值,感興趣的朋友一起看下吧2016-07-07

