Mysql 伺服器主從 主主配置

標籤：因此   存在   _for   user   下載   l資料庫   更新   主備   unix   

目錄
原理 1
主從同步配置 2
主伺服器同步處理的使用者授權 2
配置MySQL主伺服器的my.cnf檔案 3
備機配置： 4
常用命令： 5
雙主配置my.cnf 6
binlog_ignore_db引起的同步複製故障 7
常見錯誤 11
Mysql Binlog三種格式介紹及分析 11

原理
經過抓包分析，tcpdump -n -i eth0 -A -s0 -v host 218.24.23.253。當從與主處於正常串連狀態時（而不是slave第一次啟動時），主發生sql操作時，是將binlog主動推送給從伺服器。
當正常同步之後，如果Slave mysql 停止，如服務停止了，或者裝置故障了。那麼在slave重新正常後，在這期間的主的變化都會正常同步到slave。
一 MySQL 複製的基本過程如下：（各部分學習自Google，謝謝）

1. Slave 上面的IO線程串連上 Master，並請求從指定記錄檔的指定位置(或者從最開始的日誌)之後的日誌內容;
2. Master 接收到來自 Slave 的 IO 線程的請求後，通過負責複製的 IO線程根據請求資訊讀取指定日誌指定位置之後的日誌資訊，返回給 Slave 端的 IO線程。返回資訊中除了日誌所包含的資訊之外，還包括本次返回的資訊在 Master 端的 Binary Log 檔案的名稱以及在 BinaryLog 中的位置;
3. Slave 的 IO 線程接收到資訊後，將接收到的日誌內容依次寫入到 Slave 端的RelayLog檔案(mysql-relay-lin.xxxxxx)的最末端，並將讀取到的Master端的bin-log的檔案名稱和位置記錄到 master-info檔案中，以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個bin-log的哪個位置開始往後的日誌內容，請發給 我”
4. Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容後，會馬上解析該 Log 檔案中的內容成為在 Master
   端真實執行時候的那些可執行檔 Query 語句，並在自身執行這些 Query。這樣，實際上就是在 Master 端和 Slave端執行了同樣的 Query，所以兩端的資料是完全一樣的。

主從同步配置
安裝：
yum install mysql mysql-server #安裝
cp /usr/share/mysql/my-medium.cnf /etc/my.cnf #複製設定檔
service mysql start #啟動
chkconfig mysql on #設定開機自動啟動

mysql_secure_installatio n #初始化資料庫，刪除test庫；禁止root遠程登入；

mysql root密碼：[email protected][email protected]#
218.24.44.80；218.24.23.253 的mysql密碼修改為 root/[email protected]
同步用的帳號和密碼：ZHUOMING_backup/[email protected]!#%

修改mysql的服務連接埠
vim /etc/my.cnf
主伺服器同步處理的使用者授權
CREATE DATABASE backup DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 建庫
#CREATE USER ‘ZHUOMING_backup‘@‘218.24.44.80‘ IDENTIFIED BY ‘[email protected]!#%‘; 建備份用的使用者和密碼（建使用者時填寫允許使用者備份操作的IP；在給此使用者賦權時的IP必須與此相同，否則賦不上許可權）
#建使用者並授權
GRANT FILE,REPLICATION SLAVE ON . TO ‘ZHUOMING_backup‘@‘218.24.44.80‘ IDENTIFIED BY ‘[email protected]!#%‘; #給備份使用者相應的許可權，
REVOKE FILE,REPLICATION SLAVE ON . FROM ‘ZHUOMING_backup‘@‘218.24.23.232‘; #收回授權
如果中間還通過防火牆做的靜態地址映射還需要增加防火牆外網口的地址和映射用的地址，否則連不上
GRANT FILE,REPLICATION SLAVE ON . TO ‘ZHUOMING_backup‘@‘223.100.7.151‘ IDENTIFIED BY ‘[email protected]!#%‘;
GRANT FILE,REPLICATION SLAVE ON . TO ‘ZHUOMING_backup‘@‘223.100.7.155‘ IDENTIFIED BY ‘[email protected]!#%‘;
GRANT ALL PRIVILEGES ON . TO ‘ZHUOMING_backup‘@‘223.100.7.155‘ IDENTIFIED BY ‘[email protected]!#%‘;
flush privileges; 每次賦權後必須重新整理

三、把MySQL主伺服器中的資料庫osyunweidb匯入到MySQL從伺服器中
1、匯出資料庫osyunweidb
備忘：在匯出之前可以先進入MySQL控制台執行下面命令
flush tables with read lock; #生產環境必須先鎖定。資料庫唯讀鎖定命令，防止匯出資料庫的時候有資料寫入。這個命令是全域讀鎖定，執行了命令之後所有庫所有表都被鎖定唯讀。一般都是用在資料庫聯機備份，這個時候資料庫的寫操作將被阻塞，讀操作順利進行。解鎖的語句也是unlock tables。
mysqldump -u root -p osyunweidb > /home/osyunweidbbak.sql #在MySQL主伺服器進行操作，匯出資料庫osyunweidb到/home/osyunweidbbak.sql
unlock tables; #解除鎖定
2、匯入資料庫到MySQL從伺服器
mysql -u root -p #進入從伺服器MySQL控制台
create database osyunweidb; #建立資料庫
use osyunweidb #進入資料庫
source /home/osyunweidbbak.sql #匯入備份檔案到資料庫
mysql -u osyunweidbbak -h 192.168.21.169 -p #測試在從伺服器上登入到主伺服器
MySQL主伺服器配置
use backup; 將backup庫設定為當前庫
create table mytest (username varchar(20),password varchar(20)); 建立一個測試用表

vi /etc/my.cnf #編輯設定檔，在[mysqld]部分添加下面內容
server-id=1 #設定伺服器id，為1表示主伺服器，注意：如果原來的設定檔中已經有這一行，就不用再添加了。
log-bin=mysql-bin #啟動MySQL二進位日誌系統，注意：如果原來的設定檔中已經有這一行，就不用再添加了。
binlog_format = MIXED #建議使用MIXED格式。使用show variables like ‘binlog_format‘查看；
expire_logs_days = 10 #binlog到期清理時間，根據每日產生的日誌量，磁碟空間等設定到期時間。
max_binlog_size = 100M #每個記錄檔大小的最大值
binlog-do-db=backup #需要同步的資料庫名，如果有多個資料庫，可重複此參數，每個資料庫一行
binlog-ignore-db=mysql #不同步mysql資料庫
binlog-ignore-db=information_schema
binlog-ignore-db=performance_schema
service mysql restart #重啟MySQL
mysql -u root -p #進入mysql控制台

查看主伺服器，出現以下類似資訊
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 106 | backup | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

查看server-id：
mysql> show variables like ‘server_id‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
1 row in set (0.00 sec)

Mysql從伺服器配置
vi /etc/my.cnf #編輯設定檔，在[mysqld]部分添加下面內容
server-id=2 #設定檔中已經有一行server-id=1，修改其值為2，主從不能相同
log-bin=mysql-bin #啟動MySQL二進位日誌系統，如果只做從資料庫則不起也可以，建議開啟。
binlog_format = MIXED #建議使用MIXED格式。使用show variables like ‘binlog_format‘查看；
expire_logs_days = 10 #binlog到期清理時間，根據每日產生的日誌量，磁碟空間等設定到期時間。
max_binlog_size = 100M #每個記錄檔大小的最大值
read-only = 1 #設定為唯讀，以免被誤寫入而導致主從不同步，對非root使用者有效。
replicate-do-db=backup #需要同步的資料庫名，如果有多個資料庫，可重複此參數，每個資料庫一行
replicate-ignore-db=mysql #不同步mysql系統資料庫

:wq! #儲存退出
service mysql restart #重啟MySQL
注意：MySQL 5.1.7版本之後，已經不支援把master配置屬性寫入my.cnf設定檔中了，設定檔中只需要把同步的資料庫和要忽略的資料庫寫入即可。
mysql -u root -p #進入MySQL控制台
slave stop; #停止slave同步進程
進入主庫，鎖定主庫表：
flush tables with read lock; #生產環境必須先鎖定。
#執行同步語句（執行同步必須在mysql> stop slave; 的狀態下進行）
change master to master_host=‘223.100.7.155‘, MASTER_PORT=3306,master_user=‘ZHUOMING_backup‘,master_password=‘[email protected]!#%‘,master_log_file=‘mysql-bin.000001‘ ,master_log_pos=106;
start slave; #開啟slave同步進程
進入主庫，解鎖主庫標：
unlock tables;#解鎖。

SHOW SLAVE STATUS\G #查看slave同步資訊，出現以下內容
1. row
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.21.169
Master_User: osyunweidbbak
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000019
Read_Master_Log_Pos: 7131
Relay_Log_File: MySQLSlave-relay-bin.000002
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000019
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: osyunweidb
Replicate_Ignore_DB: mysql
Replicate_Do_Table:
Replicate_Ignore_Table:
1 row in set (0.00 sec)
測試：
在主備資料庫伺服器上：
CREATE DATABASE backup DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 建庫
create table cc(id int auto_increment,name varchar(20),primary key(id)); 建表
insert into cc (name) values(‘Mr.chai‘); 插資料
在備資料庫伺服器上查看是否有建立的表和資料。

常用命令：
1、使用者建立完，賦完許可權之後在備伺服器上用此命令進行測試。如果能進行登入則表明許可權和連通性沒問題。
mysql -u osyunweidbbak -h 192.168.21.169 -p #測試在從伺服器上登入到主伺服器
1、查看使用者及許可權
SELECT DISTINCT CONCAT(‘User: ‘‘‘,user,‘‘‘@‘‘‘,host,‘‘‘;‘) AS query FROM mysql.user;
Show grants for ‘ZHUOMING_backup‘@‘10.34.34.232‘;
允許root使用者從218.24.23.253訪問
mysql>GRANT ALL PRIVILEGES ON . TO ‘root‘@‘218.24.23.253‘ IDENTIFIED BY ‘[email protected]‘;
mysql> flush privileges; 修改許可權之後需要執行此句以使之生效。
1、手動同步主要資料庫；必須在slave stop的狀態下；
mysql>change master to master_host=‘223.100.7.155‘,master_user=‘ZHUOMING_backup‘,master_password=‘[email protected]!#%‘,master_log_file=‘mysql-bin.000002‘ ,master_log_pos=2394;

2、查看slave狀態
mysql> show slave status\G;

3、手動從主要資料庫下載
mysql> load data from master;

4、在主備上可以查看各自的進程狀態，主上一個BinlogDump，從上兩個一個是I/O一個是SQL進程，I/O進程負責接收更新，SQL負責寫入本地庫。
show processlist;

5、查看參數配置
show variables like ‘slave%‘;

6、查看某使用者權限
Show grants for ‘ZHUOMING_backup‘@‘218.24.23.232‘;

7、修改設定檔my.cnf，在[mysqld]下添加slave_net_timeout = 600；此參數的預設值是3600（秒，1小時），是指 slave 端（備資料庫）的 I/O 線程處於 “waiting for master to send event”狀態，如果這個等待狀態超過 slave_net_timeout 時間，就會觸發重連 master 的動作。
slave_net_timeout = 600 此參數的合理值需要在實際環境中進行一下測試，時間太長，容易導致同步不及時，時間太短，則備機會頻繁串連主機。
在一個已經建立主從複製關係的系統裡面,正常情況下,由從庫向主庫發送一個 COM_BINLOG_DUMP 命令後,主庫有新的binlog event，會向備庫發送binlog。但是由於網路故障或者其他原因（如主從資料庫之間跨防火牆）導致主庫與從庫的串連斷開或者主庫長時間沒有向從庫發送binlog。例如該例子中資料庫叢集 10s 左右還沒有寫入的情況，超過slave_net_timeout設定的值，從庫會向主庫發起重連請求。5.6 版本slave 發起重連請求時，MySQL都會判斷有沒有用明文的使用者名稱密碼,如果有則發出上述資訊到error.log。

8、--logs-slave-updates 參數
這個是在my.cnf檔案配置的
通常情況，從伺服器從主伺服器接收到的更新不記入它的二進位日誌。該選項告訴從伺服器將其SQL線程執行的更新記入到從伺服器自己的二進位日誌。為了使該 選項生效，還必須用--logs-bin選項啟動從伺服器以啟用二進位日誌。如果想要應用鏈式複製伺服器，應使用--logs-slave- updates。例如，可能你想要這樣設定：
A -> B -> C
也就是說，A為從伺服器B的主伺服器，B為從伺服器C的主伺服器。為了能工作，B必須既為主伺服器又為從伺服器。你必須用--logs-bin啟動A和B以啟用二進位日誌，並且用--logs-slave-updates選項啟動B。

在my.cnf檔案設定此選項
log_slave_updates=1
當然在這種機制下可能有的同學會存在這麼個問題：
如果a->b b->a 這樣的雙master架構下，a,b都開啟log_slave_updates選項會不會出現無限迴圈的狀態。
mysql已經考濾到了這個問題，每條bin-log都會記錄執行語句的源server_id.當slave讀到語句的server_id等於本身的ID的時候，不會執行，所以我們不用擔心a,b會不會無限迴圈下去。

基於以上這種情況，mysql的replication叢集將更加靈活，你如果需要可以做成各種各樣的鏈式複製。比如 a->b b->a b中設定log_slave_updates後還可以b->c. 這樣a,c中的資料也是一致的。

雙主配置my.cnf

1. log_slave_updates = 1 #添加(將複製事件寫入binlog,一台伺服器既做主庫又做從庫此選項必須要開啟)
2. replicate-same-server-id=0 #添加(防止MySQL迴圈更新)
3. relay_log_recovery = 1 #添加(MySQLrelay_log的自動修複功能)
   *從MySQL5.5.X版本才開始支援，增加了relay_log_recovery參數，這個參數的作用是：當slave從庫宕機後，假如relay-log損壞了，導致一部分中繼日誌沒有處理，則自動放棄所有未執行的relay-log，並且重新從master上擷取日誌，這樣就保證了relay-log的完整性。預設情況下該功能是關閉的，將relay_log_recovery的值設定為 1時，可在slave從庫上開啟該功能，建議開啟。
4. server-id：資料庫標識，每個資料庫標識必須唯一；
5. auto_increment_increment=2 ：這是迴圈鏡像裡最重要的參數之一，表示自動增量為2，就是指欄位一次遞增多少，這將允許最多2台資料庫加入這個迴圈鏡像的陣列，而自動遞增欄位不會重複。當然如果有10台主可以將這個值設成10。
6. auto_increment_offset=1 ：這是迴圈鏡像裡最重要的參數之一，表示自增欄位的起始值，每個主要資料庫的位移值必須唯一，且在1和auto_increment_increment之間（也就是說兩個主要資料庫的這個設定分別是1和2）。
   如果按以下設定，肯定不會出現這個問題，但如果業務有要求，ID必須連續，那就不能設定這兩個參數了：
   主1： 遞增初始值是1，一次遞增2。也就是值將是1、3、5.。。。
   auto-increment-increment=2
   auto-increment-offset=1
   主2： 遞增初始值是2，一次遞增2。也就是值將是2、4、6.。。。
   auto-increment-increment=2
   auto-increment-offset=2
   這樣配置之後，兩台裝置在產生auto_increment的列時就是主1是1、3、5、7奇數；主2是2、4、6、8偶數。注意，產生的值不一定連續，最後這個欄位有可能是，1、2、3、4、5、7、8、10；邏輯是這樣，假如主1 執行insert 3條記錄，則這個欄位是1、3、5，主2再執行insert的時候，是從6開始，6、8、10。然後主1再11、13、15。
   binlog_ignore_db引起的同步複製故障
   *在binlog_format 設定為ROW格式時，並且主伺服器my.cnf設定檔設定了參數：binlog_ignore_db=xxx時會出現此問題。
   將mysql的binlog_fromat 設定為MIXED格式可以解決此問題。 slave伺服器是可以同步執行-e 的操作的。
   mysql -u root -p -e "insert into backup.test values(11)"
   關於MySQL的 binlog_format 的幾中類型詳見本文最後的介紹(Mixed,Statement,Row)
   今天一個同事跟我說了一個問題，"mysql master使用了binlog_ignore_db一個庫以後，使用mysql -e 執行的所有語句就不寫binlog了？"
   詢問了他的情況，他是想在主從複製時，有一個庫不複製，查了他的my.cnf配置，binlog格式化為row，跟他要了當時的語句，如下：
   mysql -e "create table db.tb like db.tb1" 示範：

結果建立的表，Slave上一個都沒有，導致杯具發生。
到底是什麼原因引起的呢？那就是沒有使用use 庫名導致的，如果使用了，就可以記錄binlog，

所以，如果想在Slave上忽略一個庫的複製，最好不要用binlog_ignore_db這個參數，使用replicate-ignore-db = yourdb，取代之。
MySQL binlog_format (Mixed,Statement,Row)
MySQL 5.5 中對於二進位日誌 (binlog) 有 3 種不同的格式可選：Mixed,Statement,Row，預設格式是 Statement。總結一下這三種格式日誌的優缺點。

MySQL Replication 複製可以是基於一條語句 (Statement Level) ，也可以是基於一條記錄 (Row Level)，可以在 MySQL 的配置參數中設定這個複製層級，不同複製層級的設定會影響到 Master 端的 bin-log 日誌格式。

1. Row
   日誌中會記錄成每一行資料被修改的形式，然後在 slave 端再對相同的資料進行修改。
   優點：在 row 模式下，bin-log 中可以不記錄執行的 SQL 陳述式的上下文相關的資訊，僅僅只需要記錄那一條記錄被修改了，修改成什麼樣了。所以 row 的日誌內容會非常清楚的記錄下每一行資料修改的細節，非常容易理解。而且不會出現某些特定情況下的預存程序或 function ，以及 trigger 的調用和觸發無法被正確複製的問題。
   缺點：在 row 模式下，所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容，比如有這樣一條 update 語句：
   1 UPDATE product SET owner_member_id = ‘b‘ WHERE owner_member_id = ‘a‘
   執行之後，日誌中記錄的不是這條 update 語句所對應的事件 (MySQL 以事件的形式來記錄 bin-log 日誌) ，而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個事件。自然，bin-log 日誌的量就會很大。尤其是當執行 alter table 之類的語句的時候，產生的日誌量是驚人的。因為 MySQL 對於 alter table 之類的表結構變更語句的處理方式是整個表的每一條記錄都需要變動，實際上就是重建了整個表。那麼該表的每一條記錄都會被記錄到日誌中。
2. Statement
   每一條會修改資料的 SQL 都會記錄到 master 的 bin-log 中。slave 在複製的時候 SQL 進程會解析成和原來 master 端執行過的相同的 SQL 再次執行。
   優點：在 statement 模式下，首先就是解決了 row 模式的缺點，不需要記錄每一行資料的變化，減少了 bin-log 日誌量，節省 I/O 以及儲存資源，提高效能。因為他只需要記錄在 master 上所執行的語句的細節，以及執行語句時候的內容相關的資訊。
   缺點：在 statement 模式下，由於他是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那麼他還必須記錄每條語句在執行的時候的一些相關資訊，也就是上下文資訊，以保證所有語句在 slave 端杯執行的時候能夠得到和在 master 端執行時候相同的結果。另外就是，由於 MySQL 現在發展比較快，很多的新功能不斷的加入，使 MySQL 的複製遇到了不小的挑戰，自然複製的時候涉及到越複雜的內容，bug 也就越容易出現。在 statement 中，目前已經發現的就有不少情況會造成 MySQL 的複製出現問題，主要是修改資料的時候使用了某些特定的函數或者功能的時候會出現，比如：sleep() 函數在有些版本中就不能被正確複製，在預存程序中使用了 last_insert_id() 函數，可能會使 slave 和 master 上得到不一致的 id 等等。由於 row 是基於每一行來記錄的變化，所以不會出現類似的問題。
3. Mixed
   從官方文檔中看到，之前的 MySQL 一直都只有基於 statement 的複製模式，直到 5.1.5 版本的 MySQL 才開始支援 row 複製。從 5.0 開始，MySQL 的複製已經解決了大量老版本中出現的無法正確複製的問題。但是由於預存程序的出現，給 MySQL Replication 又帶來了更大的新挑戰。另外，看到官方文檔說，從 5.1.8 版本開始，MySQL 提供了除 Statement 和 Row 之外的第三種複製模式：Mixed，實際上就是前兩種模式的結合。在 Mixed 模式下，MySQL 會根據執行的每一條具體的 SQL 陳述式來區分對待記錄的日誌形式，也就是在 statement 和 row 之間選擇一種。新版本中的 statment 還是和以前一樣，僅僅記錄執行的語句。而新版本的 MySQL 中對 row 模式也被做了最佳化，並不是所有的修改都會以 row 模式來記錄，比如遇到表結構變更的時候就會以 statement 模式來記錄，如果 SQL 陳述式確實就是 update 或者 delete 等修改資料的語句，那麼還是會記錄所有行的變更。
   其他參考資訊
   除以下幾種情況外，在運行時可以動態改變 binlog 的格式：
   . 儲存流程或者觸發器中間；
   . 啟用了 NDB；
   . 當前會話使用 row 模式，並且已開啟了暫存資料表；
   如果 binlog 採用了 Mixed 模式，那麼在以下幾種情況下會自動將 binlog 的模式由 statement 模式變為 row 模式：
   . 當 DML 語句更新一個 NDB 表時；
   . 當函數中包含 UUID() 時；
   . 2 個及以上包含 AUTO_INCREMENT 欄位的表被更新時；
   . 執行 INSERT DELAYED 語句時；
   . 用 UDF 時；
   . 視圖中必須要求運用 row 時，例如建立視圖時使用了 UUID() 函數；
   設定主從複製模式：
   1
   2
   3
   4 log-bin=mysql-bin
   #binlog_format="STATEMENT"
   #binlog_format="ROW"
   binlog_format="MIXED"
   也可以在運行時動態修改 binlog 的格式。例如：
   1
   2
   3
   4
   5
   6 mysql> SET SESSION binlog_format = ‘STATEMENT‘;
   mysql> SET SESSION binlog_format = ‘ROW‘;
   mysql> SET SESSION binlog_format = ‘MIXED‘;
   mysql> SET GLOBAL binlog_format = ‘STATEMENT‘;
   mysql> SET GLOBAL binlog_format = ‘ROW‘;
   mysql> SET GLOBAL binlog_format = ‘MIXED‘;
   兩種模式的對比：
   Statement 優點
   曆史悠久，技術成熟；
   產生的 binlog 檔案較小；
   binlog 中包含了所有資料庫修改資訊，可以據此來審核心數據庫的安全等情況；
   binlog 可以用於即時的還原，而不僅僅用於複製；
   主從版本可以不一樣，從伺服器版本可以比主伺服器版本高；
   Statement 缺點：
   不是所有的 UPDATE 語句都能被複製，尤其是包含不確定操作的時候；
   調用具有不確定因素的 UDF 時複製也可能出現問題；
   運用以下函數的語句也不能被複製：
   • LOAD_FILE()
   • UUID()
   • USER()
   • FOUND_ROWS()
   • SYSDATE() (除非啟動時啟用了 –sysdate-is-now 選項)
     INSERT … SELECT 會產生比 RBR 更多的行級鎖；
     複製須要執行全表掃描 (WHERE 語句中沒有運用到索引) 的 UPDATE 時，須要比 row 請求更多的行級鎖；
     對於有 AUTO_INCREMENT 欄位的 InnoDB 表而言，INSERT 語句會阻塞其他 INSERT 語句；
     對於一些複雜的語句，在從伺服器上的耗資源情況會更嚴重，而 row 模式下，只會對那個發生變化的記錄產生影響；
     儲存函數(不是儲存流程 )在被調用的同時也會執行一次 NOW() 函數，這個可以說是壞事也可能是好事；
     確定了的 UDF 也須要在從伺服器上執行；
     資料表必須幾乎和主伺服器保持一致才行，否則可能會導致複製出錯；
     執行複雜語句如果出錯的話，會消耗更多資源；
     Row 優點
     任何情況都可以被複製，這對複製來說是最安全可靠的；
     和其他大多數資料庫系統的複製技能一樣；
     多數情況下，從伺服器上的表如果有主鍵的話，複製就會快了很多；
     複製以下幾種語句時的行鎖更少：
   • INSERT … SELECT
   • 包含 AUTO_INCREMENT 欄位的 INSERT
   • 沒有附帶條件或者並沒有修改很多記錄的 UPDATE 或 DELETE 語句
     執行 INSERT，UPDATE，DELETE 語句時鎖更少；
     從伺服器上採用多線程來執行複製成為可能；
     Row 缺點
     產生的 binlog 日誌體積大了很多；
     複雜的復原時 binlog 中會包含大量的資料；
     主伺服器上執行 UPDATE 語句時，所有發生變化的記錄都會寫到 binlog 中，而 statement 只會寫一次，這會導致頻繁發生 binlog 的寫並發請求；
     UDF 產生的大 BLOB 值會導致複製變慢；
     不能從 binlog 中看到都複製了寫什麼語句(加密過的)；
     當在非事務表上執行一段堆積的 SQL 陳述式時，最好採用 statement 模式，否則很容易導致主從伺服器的資料不一致情況發生；
     另外，針對系統庫 MySQL 裡面的表發生變化時的處理準則如下：
     如果是採用 INSERT，UPDATE，DELETE 直接動作表的情況，則日誌格式根據 binlog_format 的設定而記錄；
     如果是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那麼無論如何都要使用 statement 模式記錄；
     使用 statement 模式後，能處理很多原先出現的主鍵重複問題；

常見錯誤
mysql主從複製，經常會遇到錯誤而導致slave端複製中斷，這個時候一般就需要人工幹預，跳過錯誤才能繼續
跳過錯誤有兩種方式：
1.跳過指定數量的事務：
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; #跳過一個事務
mysql>slave start;

2.修改mysql的設定檔，通過slave_skip_errors參數來跳所有錯誤或指定類型的錯誤
vi /etc/my.cnf
[mysqld]
#slave-skip-errors=1062,1053,1146 #跳過指定error no類型的錯誤
#slave-skip-errors=all #跳過所有錯誤

Mysql Binlog三種格式介紹及分析
一．Mysql Binlog格式介紹
Mysql binlog日誌有三種格式，分別為Statement,MiXED,以及ROW！
1.Statement：每一條會修改資料的sql都會記錄在binlog中。
優點：不需要記錄每一行的變化，減少了binlog日誌量，節約了IO，提高效能。(相比row能節約多少效能與日誌量，這個取決於應用的SQL情況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，但是考慮到如果帶條件的update操作，以及整表刪除，alter表等操作，ROW格式會產生大量日誌，因此在考慮是否使用ROW格式日誌時應該跟據應用的實際情況，其所產生的日誌量會增加多少，以及帶來的IO效能問題。)
缺點：由於記錄的只是執行語句，為了這些語句能在slave上正確運行，因此還必須記錄每條語句在執行的時候的一些相關資訊，以保證所有語句能在slave得到和在master端執行時候相同 的結果。另外mysql 的複製,像一些特定函數功能，slave可與master上要保持一致會有很多相關問題(如sleep()函數， last_insert_id()，以及user-defined functions(udf)會出現問題).
使用以下函數的語句也無法被複製：

• LOAD_FILE()
• UUID()
• USER()
• FOUND_ROWS()
• SYSDATE() (除非啟動時啟用了 --sysdate-is-now 選項)
  同時在INSERT ...SELECT 會產生比 RBR 更多的行級鎖
  2.Row:不記錄sql語句上下文相關資訊，僅儲存哪條記錄被修改。
  優點： binlog中可以不記錄執行的sql語句的上下文相關的資訊，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行資料修改的細節。而且不會出現某些特定情況下的預存程序，或function，以及trigger的調用和觸發無法被正確複製的問題
  缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容,比如一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣造成binlog日誌量會很大，特別是當執行alter table之類的語句的時候，由於表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中。
  3.Mixedlevel: 是以上兩種level的混合使用，一般的語句修改使用statment格式儲存binlog，如一些函數，statement無法完成主從複製的操作，則採用row格式儲存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊row level模式也被做了最佳化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄。至於update或者delete等修改資料的語句，還是會記錄所有行的變更。

二.Binlog基本配製與格式設定
1.基本配製
Mysql BInlog日誌格式可以通過mysql的my.cnf檔案的屬性binlog_format指定。如以下：
binlog_format = MIXED //binlog日誌格式
log_bin =目錄/mysql-bin.log //binlog日誌名
expire_logs_days = 7 //binlog到期清理時間
max_binlog_size 100m //binlog每個記錄檔大小
2.Binlog日誌格式選擇
Mysql預設是使用Statement日誌格式，推薦使用MIXED.
由於一些特殊使用，可以考慮使用ROWED，如自己通過binlog日誌來同步資料的修改，這樣會節省很多相關操作。對於binlog資料處理會變得非常輕鬆,相對mixed，解析也會很輕鬆(當然前提是增加的日誌量所帶來的IO開銷在容忍的範圍內即可)。
3.mysqlbinlog格式選擇
mysql對於日誌格式的選定原則:如果是採用 INSERT，UPDATE，DELETE 等直接動作表的情況，則日誌格式根據 binlog_format 的設定而記錄,如果是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那麼無論如何 都採用 SBR 模式記錄

三．Mysql Binlog日誌分析
通過MysqlBinlog指令查看具體的mysql日誌，如下:
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
SET TIMESTAMP=1350355892/!/;
BEGIN
/!/;

at 1643330

#121016 10:51:32 server id 1 end_log_pos 1643885 Query thread_id=272571 exec_time=0 error_code=0
SET TIMESTAMP=1350355892/!/;
Insert into T_test….)
/!/;

at 1643885

#121016 10:51:32 server id 1 end_log_pos 1643912 Xid = 0
COMMIT/!/;
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1.開始事物的時間:
SET TIMESTAMP=1350355892/!/;
BEGIN
2.sqlevent起點
#at 1643330 :為事件的起點，是以1643330位元組開始。
3.sqlevent 發生的時間點
#121016 10:51:32:是事件發生的時間，
4.serverId
server id 1 :為master 的serverId
5.sqlevent終點及花費時間，錯誤碼
end_log_pos 1643885:為事件的終點，是以1643885 位元組結束。
execTime 0: 花費的時間
error_code=0:錯誤碼
Xid:事件指示提交的XA事務
Mixed日誌說明：
在slave日誌同步過程中，對於使用now這樣的時間函數，MIXED日誌格式，會在日誌中產生對應的unix_timestamp()*1000的時間字串，slave在完成同步時，取用的是sqlEvent發生的時間來保證資料的準確性。另外對於一些功能性函數slave能完成相應的資料同步，而對於上面指定的一些類似於UDF函數，導致Slave無法知曉的情況，則會採用ROW格式儲存這些Binlog，以保證產生的Binlog可以供Slave完成資料同步。

Mysql 伺服器主從 主主配置