mysql主從同步操作

首先說下同步原理:
Replication 線程
   Mysql的 Replication 是一個異步的複製過程,從一個 Mysql instace(我們稱之爲 Master)複製到另一個 Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個線程來完成,其中兩個線程(Sql線程和IO線程)在 Slave 端,另外一個線程(IO線程)在 Master 端。
  要實現 MySQL 的 Replication ,首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否則無法實現。因爲整個複製過程實際上就是Slave從Master端獲取該日誌然後再在自己身上完全 順序的執行日誌中所記錄的各種操作。打開 MySQL 的 Binary Log 可以通過在啓動 MySQL Server 的過程中使用 “—log-bin” 參數選項,或者在 my.cnf 配置文件中的 mysqld 參數組([mysqld]標識後的參數部分)增加 “log-bin” 參數項。
  MySQL 複製的基本過程如下:
  1. Slave 上面的IO線程連接上 Master,並請求從指定日誌文件的指定位置(或者從最開始的日誌)之後的日誌內容;
   2. Master 接收到來自 Slave 的 IO 線程的請求後,通過負責複製的 IO 線程根據請求信息讀取指定日誌指定位置之後的日誌信息,返回給 Slave 端的 IO 線程。返回信息中除了日誌所包含的信息之外,還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 Binary Log 中的位置;
  3. Slave 的 IO 線程接收到信息後,將接收到的日誌內容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,並將讀取到的Master端的bin-log的文件名和位置記錄到master- info文件中,以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log的哪個位置開始往後的日誌內容,請發給我”
   4. Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容後,會馬上解析該 Log 文件中的內容成爲在 Master 端真實執行時候的那些可執行的 Query 語句,並在自身執行這些 Query。這樣,實際上就是在 Master 端和 Slave 端執行了同樣的 Query,所以兩端的數據是完全一樣的。
  實際上,在老版本中,MySQL 的複製實現在 Slave 端並不是由 SQL 線程和 IO 線程這兩個線程共同協作而完成的,而是由單獨的一個線程來完成所有的工作。但是 MySQL 的工程師們很快發現,這樣做存在很大的風險和性能問題,主要如下:
   首先,如果通過一個單一的線程來獨立實現這個工作的話,就使複製 Master 端的,Binary Log日誌,以及解析這些日誌,然後再在自身執行的這個過程成爲一個串行的過程,性能自然會受到較大的限制,這種架構下的 Replication 的延遲自然就比較長了。
   其次,Slave 端的這個複製線程從 Master 端獲取 Binary Log 過來之後,需要接着解析這些內容,還原成 Master 端所執行的原始 Query,然後在自身執行。在這個過程中,Master端很可能又已經產生了大量的變化並生成了大量的 Binary Log 信息。如果在這個階段 Master 端的存儲系統出現了無法修復的故障,那麼在這個階段所產生的所有變更都將永遠的丟失,無法再找回來。這種潛在風險在Slave 端壓力比較大的時候尤其突出,因爲如果 Slave 壓力比較大,解析日誌以及應用這些日誌所花費的時間自然就會更長一些,可能丟失的數據也就會更多。
   所以,在後期的改造中,新版本的 MySQL 爲了儘量減小這個風險,並提高複製的性能,將 Slave 端的複製改爲兩個線程來完成,也就是前面所提到的 SQL 線程和 IO 線程。最早提出這個改進方案的是Yahoo!的一位工程師“Jeremy Zawodny”。通過這樣的改造,這樣既在很大程度上解決了性能問題,縮短了異步的延時時間,同時也減少了潛在的數據丟失量。
  當然,即使是換成了現在這樣兩個線程來協作處理之後,同樣也還是存在 Slave 數據延時以及數據丟失的可能性的,畢竟這個複製是異步的。只要數據的更改不是在一個事務中,這些問題都是存在的。
  如果要完全避免這些問題,就只能用 MySQL 的 Cluster 來解決了。不過 MySQL的 Cluster 知道筆者寫這部分內容的時候,仍然還是一個內存數 據庫的解決方案,也就是需要將所有數據包括索引全部都 Load 到內存中,這樣就對內存的要求就非常大的大,對於一般的大衆化應用來說可實施性並不是太大。當然,在之前與 MySQL 的 CTO David 交流的時候得知,MySQL 現在正在不斷改進其 Cluster 的實現,其中非常大的一個改動就是允許數據不用全部 Load 到內存中,而僅僅只是索引全部 Load 到內存中,我想信在完成該項改造之後的 MySQL Cluster 將會更加受人歡迎,可實施性也會更大。

 一、測試環境:
主庫(Master):Centos 5.5 64位操作系統

Mysql Server version: 5.1.59
IP:192.168.1.188

從庫(Slave):Centos 5.5 64位操作系統
Mysql Server version: 5.1.59

IP:192.168.1.189

 

權限管理:GRANT privileges ON db TO user@host IDENTIFIED BY "password" WITH GRANT OPTION

Privileges==alter 、select、create、 delect、 drop 、index、 insert 、replication slave 等

常見問題:Slave_IO_Running: No

1.先檢查防火牆設置(測試前最好關閉)

2.所有操作完後,注意要重啓mysql服務 

 

二、主庫的操作

#vi /etc/my.cnf
server-id             = 1

my.cnf內容比較多,這裏只介紹一些重要參數
server-id = 1 這是數據庫ID,此ID唯一,主庫用默認的1即可,從庫調整爲2,多個從庫的ID依次類推,切不可有相同ID出現,這樣會造成同步出錯。

 
log-bin=mysql-bin 二進制日誌文件,此項必須啓用,從庫需要通過它進行數據同步。
配置主庫其實就檢查這2個選項,如果你同步的數據庫不是全部的,只是同步個別庫,或個別的不需要同步,需要繼續往下看

binlog-do-db=test 需要同步的數據庫,如果同步多個庫,需要另行重寫,如
binlog-do-db=test1
binlog-do-db=test2
(數據庫安裝包不同這個選項有的配置文件裏沒有,需要加上)

binlog-ignore-db=mysql 不需要同步的數據庫,與binlog-do-db正好相反,如果你有100個庫,只想同步其中幾個,那麼你應該使用binlog-do-db,如果不想同步其中的幾個,就使用binlog-ignore-db
(數據庫安裝包不同這個選項有的配置文件裏沒有,需要加上)

 

建立同步用的數據庫賬戶
主庫必須提供一個賬戶讓從庫通過此賬戶進行連接並進行同步,進入mysql後輸入下面命令

mysql> grant replication slave on *.* to [email protected] identified by '123456';

鎖住主庫表,停止數據更新

Mysql> flush tables with read lock;
打開另一個shell窗口
Shell> cd /var/lib/
Shell> tar -zcvf mysqlbak.tar.gz mysql

(另外一種打包數據庫的方法: Shell> mysqldump --opt --default-character-set=utf8 --master-data --databases castlot warlog assist > castlot120116.sql

Shell>vim castlot120116.sql 查看File和Position並記錄)

Mysql>show master status;

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000073 |       98 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Mysql> unlock tables;

 

將mysqlbak.tar.gz拷貝到叢庫數據庫目錄下並解壓
Shell>scp mysqlbak.tar.gz [email protected]:/usr/local/

 

三、從庫的操作

Shell>cd /usr/local

Shell>tar -zxvf mysqlbak.tar.gz

(另一種對應方法:Shell>mysql -S /tmp/mysql.sock --default-character-set=utf8 < castlot120116.sql)

將叢庫my.cnf中server-id=1修改爲server-id=2

增加要同步的數據庫:

replicate-wild-do-table=assist.%

replicate-wild-do-table=castlot.%

replicate-wild-do-table=warlog.%

重啓下mysql

之前先stop slave

設置連接MASTER MASTER_LOG_FILE爲主庫的File:mysql-bin.000073,MASTER_LOG_POS爲主庫的Position:98

mysql> change master to
master_host='192.168.1.188',
master_user='syncuser',
master_password='123456',
master_log_file='mysql-bin.000073',
master_log_pos=98;
Mysql> start slave;

 

檢查從庫是否正常同步
mysql>show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.188
                  Master_User: syncuser
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000073
          Read_Master_Log_Pos: 98
               Relay_Log_File: TMac-relay-bin.000073
                Relay_Log_Pos: 12753
        Relay_Master_Log_File: mysql-bin.000073
             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:
          

發佈了73 篇原創文章 · 獲贊 4 · 訪問量 7萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章