MySQL集群(二)之主主復制


前面介紹了主從復制,這一篇我將介紹的是主主復制,其實聽名字就可以知道,主主復制其實就是兩台服務器互為主節點與從節點。接下來我將詳細的給大家介紹,怎么去配置主主復制!

一、主從復制中的問題

1.1、從節點占用了主節點的自增id

  環境:

    主節點:zyhserver1=1.0.0.3

    從節點:udzyh1=1.0.0.5

  第一步:我們在主節點中創建一個數據庫db_love_1,在創建一個表tb_love(里面有id自增和name屬性)。

  create database db_love_1;
  use db_love_1;
  create table tb_love( id int primary key auto_increment, name varchar(30));

  第二步:在主節點中添加一條數據,我們可以在主從節點中都可以看到這條數據都有了

  insert into tb_love(name)values('zhangsan');

  第三步:如果我們在從節點中加入一條數據

  insert into tb_love(name)values('lisi');

    在從節點中:在主節點中:

    這是自然的因為我們是主從復制,只有主節點寫的數據才能同步到從節點中,從節點中的數據是不能同步同主節點中的。因為從節點並沒有二進制日志文件,而主節點也沒有中繼日志文件,去完成相應的功能。

  第四步:如果我們在主節點中在插入一條數據

   insert into tb_love(name)values('wangwu');

   在主節點中:在從節點中:

  分析:這時候我們會發現從節點並沒有更新主節點的wangwu這條數據,因為從節點中的id為2的位置已經被占了,然后我們在來看一下從節點的狀態:

      

  在這里我們可以看到從節點的IO線程是開啟的,而SQL線程是關閉的。這樣就導致了主從關系斷裂了,那我們要怎么去恢復它呢?

    我們先在從節點中stop  slave,然后進行reset slave,然后重新來進行在從節點中change master to。

1.2、主從關系建立前的前提

  其實在建立主從關系之前,我們需要保證兩點:

  1)一是數據庫和表的結構是一樣的,也就是說主節點中有哪些數據庫和表從節點也應該有哪些數據庫和表。

    (如果說主節點中有個數據庫是從節點中沒有的,那當我們刪除這個數據庫時,從節點沒有就會出錯了)

  2)二是保證主從節點的:數據庫主鍵自增的步長一致,但是自增起始位置位置不一致。

    (一個從1開始自增,則生成的主鍵為:1,3,5,7,9。另一個從2開始自增,生成的主鍵為:2,4,6,810)

   如果是雙主的話其實沒必要設置的,但是如果是主從模式並且主節點和從節點都能插入數據的話,這樣從節點插入的數據不能同步到主節點。
   如果主節點再插入ID相同的數據之后在同步到從節點的時候就出錯了。
  那要怎么去設置呢?
    臨時設置:
  主節點的MySQL終端執行:
      set auto_increment_increment=2
      set auto_increment_offset=1
  從節點的MySQL終端執行:
      set auto_increment_increment=2
      set auto_increment_offset=2

    永久設置,如果是重啟了MySQL服務還是要重新設置:

  主節點的MySQL終端執行:
      set global auto_increment_increment=2
      set global auto_increment_offset=1
  從節點的MySQL終端執行:
      set global auto_increment_increment=2
      set global auto_increment_offset=2 

1.3、在搭建MySQL集群主從復制的時候遇到的問題

  1)查看slave的狀態出現的是

    

    查看你change的時候host(這里最好使用ip)、port、user、password、fileN、pos是否正確。

    有沒有真的創建了用戶zyh。如果還不行在查看一下兩台服務器能不能ping通。

  2)主節點主機能ping通從節點,反過來不行

    因為我們在VMware中安裝的兩台虛擬機,一個用的是橋接模式,一個用的是NAT模式,所以

    我把橋接模式改成了NAT模式就有用了。

1.4、理解binary-log文件的內容獲取

  Slave 的 IO 線程接收到信息后,將接收到的日志內容依次寫入到 Slave 端的RelayLog 文件(MySQL-relay-bin.xxxxxx)的最末端,並將讀取到的Master 端的bin-log 的文件名和位置記錄到master-info 文件中

  Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容后,會馬上解析該 Log 文件中的內容成為在 Master 端真實執行時候的那些可執行的 Query 語句,並在自身執行這些 Query。

  分析:slave的IO線程讀到的SQL語句,是怎么來的?其實它並不能直接獲取到主節點中寫入的SQL語句。而是通過查詢(分析)主節點中數據變化結果(如插入、刪除、修改操作)

        ,來自己生成SQL語句存入到二進制日志文件中,所以為什么我們在主節點中指定查詢語句,從節點不會去做查詢操作了。

二、主主復制

其實我們學會了主從復制,那主主復制理解起來就是相當的簡單了。不就是在主節點中配置從節點,從節點加上主節點的配置嗎!

2.1、主主復制理解 

  1)在slave節點授權賬號
  2) 在master節點進行slave配置,將原來的slave當做master進行連接

   

2.2、主主復制過程

  環境:

  ubuntu的server版:1.0.0.3==server1(主節點)

  ubuntu的desktop版(兩台):1.0.0.5=udzyh1(從節點)

  1)其實我們一開始的配置(mysqld.cnf文件中)是server1——>udzyh1:

    在主節點中:

  server-id=11
  log-bin=mysql-bin-11
  binlog-format=rpw

    在從節點中: 

server-id=12
relay-log=mysql-relay-12

  2)我們需要把從節點的配置加到主節點中,主節點的配置加到從節點中

    在主節點加上:

  relay-log=mysql-relay-11  

    在從節點上加上: 

  lob-bin=mysql-bin-12
  binlog-format=row

    當我們重啟服務的時候就可以在/var/lib/mysql下主節點會生成中繼日志文件,而從節點就會生成二進制日志文件了。我們還是在配置文件

    中加上skip-name-resolve把反向域名解析關閉,可以加快運行(只是關閉MySQL的)

  3)連接

  在udzyh1中運行:grant replication slave,replication client on *.* to 'zyh'@'%' identified by '123456';(在主節點創建一個用戶)

  然后在server1中的MySQL終端運行:

    

  4)然后在server1中開啟主從復制

    start slave

   注意:有兩個常用的操作

  show binary logs;作用和show master status \G一樣
  show binlog events in 'mysql-bin-11.0000001' \G

 

三、MySQL集群的主主復制的深入探討

3.1、解決主鍵沖突問題

  1)如果為簡單的兩台節點,可以讓第一台節點id自增步長為2 起點為1,讓第二台節點id自增步長為2 起點為2
  set session/ set global auto_increment_increment=2
  set session / set global auto_increment_offset=1

  2) 利用主鍵生成程序或者主鍵服務器  

3.2、Mysql 集群的被動主主復制

  兩台服務器都互為master 但是其中一台為只讀服務器,不能插入修改數據。
  在只讀服務器的my.conf配置文件中 添加 read-only=1(對於擁有super權限的用戶,可以ignore這個選項) ,目的主要是為了備份master服務器

  

    注意:但是我們一般不會這樣做,我們會通過mysql-proxy來完成(后面講解)

3.3、節點的部署方式

  

    不能讓一台slave節點,復制多台master節點

    

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM