MySQL主從架構及基於SSL實現資料複製

 MySQL主從架構及基於SSL實現資料複製

一：Mysql主從架構拓撲圖:
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QUD5-0.png" border="0" alt="" />

二： MySQL主從架構相關知識點

 

  
在MySQL的主從架構中,有關鍵的三個線程: 
  
dump thread ：當主伺服器上的有使資料庫發生改變的操作的語句時基於語句，基於行的，混合三種語句）
  
會先將改動作陳述式記錄到二進位log中，該線程通知從伺服器有資料庫動作陳述式發生,讓從伺服器的I/O thread 複製 
  
I/O thread：監控主服器的二進位log ，及傳輸資料庫動作陳述式，將這些語句記錄到中繼日誌(relay log)中 
  
SQL thread：執行從伺服器中的中繼日誌語句，到資料庫儲存中。 
  
 
  
在MySQL 5.5版本中的主從架構中的主伺服器中為了處理高並發業務時可能是多線程寫入，
  
而在從伺服器的SQL thread是單線程寫入資料庫儲存中的，這可能會造成從資料庫滯後的問題 
 

三：MySQL的主從架構的過程

 

  
首先建立MySQL資料庫的Master172.16.10.4）和Slave172.16.10.5）之間為主從關係 
  
Master的server-id:1 
  
Slave的server-id:15
  
Master： 
  
啟用二進位日誌 
  
設定server-id 
  
建立具有複製許可權的使用者，且需要ssl認證 
  
Slave： 
  
啟用中繼日誌 
  
設定server-id 
  
啟動Slave服務,並指定Master的相關參數 
  
最後為Mater和Slave先建立ssh串連需要的認證，密鑰
  
關於認證，密鑰的實現請參看---> http://haicang.blog.51cto.com/2590303/897660
 

• 主伺服器配置

 

  
1：開啟二進位日誌 
  
2：修改server-id 為1 
  
3：建立具有複製許可權的使用者mysql及為其提供redhat的密碼 
 

 

  
mysql> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO  mysql@'172.16.10.5' IDENTIFIED BY 'redhat'  REQUIRE SSL; 
 

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QWZ5-1.png" border="0" alt="" />

•   從伺服器配置

 

  
開啟中繼日誌 
  
修改server-id為15 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QV619-2.png" border="0" alt="" />

• 主從伺服器基於ssl複製的功能配置：

 

  
Master和Slave都開啟have_ssl。 
  
都在在設定檔中開啟 have-openssl選項，並添加認證，密碼相關資訊
  
主伺服器配置：
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QWY5-3.png" border="0" alt="" /> 

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QTQ5-4.png" border="0" alt="" />註：重啟MySQL服務查看開啟狀態

從伺服器的配置建議使用CHANGE MASTER TO 命令

 

  
CHANGE MASTER TO  
  
->MASTER_HOST='172.16.10.4', 
  
->MASTER_USER='mysql', 
  
->MASTER_PASSWORD='redhat', 
  
->MASTER_LOG_FILE='msql-bin.000001', 
  
->MASTER_LOG_POS=107 
  
 
  
CHANGE MASTER TO 
  
-> MASTER_SSL=1 
  
->MASTER_SSL_CA="/etc/pki/CA/cacert.pem", 
  
->MASTER_SSL_CERT="/usr/local/mysql/ssh/Slave.crt", 
  
->MASTER_SSL_KEY="/usr/local/mysql/ssh/Slave.key"; 
  
 
  
START SLAVE; 
  
SHOW SLAVE STATUS; 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QUa4-5.png" border="0" alt="" />

 

  
詳見官方文檔：http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-ssl.h
  
tml 
  
   

    
另外在主從架構中為了確保事務型引擎的資料庫的資料一致性建議配置如下” 
    
主伺服器： 
    
sync_binlog=1---------->在事物未提交的情況下，寫入二進位log 
    
innodb_flush_logs_at_trx_commit=1 
    
 
    
從伺服器： 
    
skip_slave_start=1-禁制下面兩個進程隨著MySQL服務自動啟動 
    
                      Slave_IO_Running: Yes 
    
                     Slave_SQL_Running: Yes 
    
read_only=1 
   
 

• 驗證MySQL伺服器的主從複製

 

  
主伺服器:建立student表 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QWX7-6.png" border="0" alt="" />

 

  
查看從伺服器 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QTT9-7.png" border="0" alt="" />

四 ：在配置過程中遇到的問題

 

  
查看從伺服器日誌 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QS910-8.png" border="0" alt="" /> 從日誌中 可以發現 可能是由於從伺服器的 中繼日誌導致的 。

 

  
解決方案： 
  
先停止MySQL伺服器：service mysqld stop 
  
rm -fr master.info  
  
rm -fr relay-log.info 
  
在設定檔/etc/my.cnf中添加 skip-slave-start 
  
service mysqld start 
  
登陸mysql 
  
mysql> show master status; 
  
+------------------+----------+--------------+------------------+ 
  
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | 
  
+------------------+----------+--------------+------------------+ 
  
| mysql-bin.000011 |       107 |              |                  |  
  
+------------------+----------+--------------+------------------+ 
  
再次執行： 
  
change master to 命令 
  
Query OK, 0 rows affected (0.02 sec) 
  
mysql> start slave; 
  
確保Slave¬_IO_Running和Slave¬_SQL_Running為yes狀態 
 

 

  
查看結果 
 

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QWM3-9.png" border="0" alt="" />

 

  
配置完成後啟動從伺服器時出現error 1236錯誤如下 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QV5U-10.png" border="0" alt="" />

 

  
尋找從伺服器的日誌
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QV952-11.png" border="0" alt="" />

 

  
從日誌中可以看出，是從伺服器在尋找主伺服器最新的二進位log時時出錯，下面是從伺服器的相關資訊 
 

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QQ559-12.png" border="0" alt="" />

 

  
查看主伺服器 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QQB2-13.png" border="0" alt="" />

 

  
對比發現，從伺服器指向的最新二進位日誌與主伺服器不一致導致出錯 
  
修改如下： 
 
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/193QSN9-14.png" border="0" alt="" />

五 ：總結 

 

  
查看錯誤記錄檔，及Goolge ，及在出現問題，要找到問題出現的原因，許多問題都是可以迎刃而解的。
  
這點小小的經驗，希望能給大家帶來協助，彼此共勉吧，呵呵！ 
 

本文出自 “好望角” 部落格，請務必保留此出處http://haicang.blog.51cto.com/2590303/958370