The MySQL server is running with the –skip-grant-tables option so it cannot execute this statement
解決辦法：
mysql> set global read_only=0;
（關掉新主庫的只讀屬性）
flush privileges;
set global read_only=1;(讀寫屬相)
flush privileges;
Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.
mysql> SET SESSION binlog_format = ‘ROW’;
mysql> SET GLOBAL binlog_format = ‘ROW’;
MYSQL5.1複製參數binlogformat
MySQL 5.1 中，在複製方面的改進即便引進了新的複製技巧：基於行的複製。簡言之，這種新技巧即便關懷錶中發生改變的登記，而非過去的照抄 binlog 形式。從 MySQL 5.1.12 開始，能夠用以下三種形式來告終：基於SQL語句的複製(statement-based replication, SBR)，基於行的複製(row-based replication, RBR)，混雜形式複製(mixed-based replication, MBR)。相應地，binlog的款式也有三種：STATEMENT，ROW，MIXED。MBR 形式中，SBR 形式是默認的。
在運行時能夠動態低改換binlog的款式，除非以下幾種情形：
存儲過程可能引發器其中
啓用了NDB
目前會話試用 RBR 形式，並且已敞開了臨時表
萬一binlog批准了 MIXED 形式，那麼在以下幾種情形下會積極將binlog的形式由 SBR 形式改成 RBR 形式。
當DML語句更新一個NDB表時
當函數中包括 UUID() 時
2個及以上包括 AUTO_INCREMENT 字段的表被更新時
行任何 INSERT DELAYED 語句時
用 UDF 時
視圖中定然要求利用 RBR 時，例如創立視圖是利用了 UUID() 函數
設定主從複製形式的措施極其容易，凡是在過去設定複製搭配的基礎上，再加一個參數：
binlog_format=”STATEMENT”
binlog_format=”ROW”
binlog_format=”MIXED”
當然了，也能夠在運行時動態修正binlog的款式。例如
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’;
目前來比擬以下 SBR 和 RBR 2中形式各自的優缺點
SBR 的優點：
歷史悠久，技巧成熟
binlog文件較小
binlog中包括了所有數據庫改動消息，能夠據此來覈實數據庫的平安等情形
binlog能夠用於實時的還原，而不但僅用於複製
主從版本能夠不一樣，從服務器版本能夠比主服務器版本高
SBR 的缺點：
不是所有的UPDATE語句都能被複制，尤其是包括不確定壟斷的時候。
調用具有不確定因素的 UDF 時複製也可能出問題
利用以下函數的語句也無法被複制：
- LOAD_FILE()
- UUID()
- USER()
- FOUND_ROWS()
- SYSDATE() (除非啓用時啓用了 –sysdate-is-now 選項)
INSERT … SELECT 會發生比 RBR 更多的行級鎖
複製必需舉行全表掃描(WHERE 語句中沒利於用到索引)的 UPDATE 時，必需比 RBR 哀求更多的行級鎖
對於有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其他 INSERT 語句
對於一些混雜的語句，在從服務器上的耗資源情形會更嚴重，而 RBR 形式下，只會對那個發生改變的登記發生波及
存儲函數(不是存儲過程)在被調用的同時也會厲行順次 NOW() 函數，這個能夠說是壞事也可能是好事
確定了的 UDF 也必需在從服務器上厲行
數據表定然幾乎和主服務器堅持統一才行，否則可能會導致複製出錯
厲行混雜語句萬一出錯的話，會花費更多資源
RBR 的優點：
任何情形都能夠被複制，這對複製來說是最平安可靠的
和其他大多數數據庫系統的複製技巧一樣
多數情形下，從服務器上的表萬一有主鍵的話，複製就會快了許多
複製以下幾種語句時的行鎖更少：
- INSERT … SELECT
- 包括 AUTO_INCREMENT 字段的 INSERT
- 未曾附帶條件可能並未曾修正許多登記的 UPDATE 或 DELETE 語句
厲行 INSERT，UPDATE，DELETE 語句時鎖更少
從服務器上批准多線程來厲行復製成爲可能
RBR 的缺點：
binlog 大了許多
混雜的回滾時 binlog 中會包括許多的數據
主服務器上厲行 UPDATE 語句時，所有發生改變的登記都會寫到 binlog 中，而 SBR 只會寫順次，這會導致頻繁發生
binlog 的併發寫問題
UDF 發生的大 BLOB 值會導致複製變慢
無法從 binlog 中看到都複製了寫什麼語句
當在非事務表上厲行一段堆積的SQL語句時，良好批准 SBR 形式，否則很輕率導致主從服務器的數據不統一情形發生
另外，針對系統庫 mysql 裏面的表發生改變時的處理法定如下：
萬一是批准 INSERT，UPDATE，DELETE 直接壟斷表的情形，則日誌款式依據 binlog_format 的設定而登記
萬一是批准 GRANT，REVOKE，SET PASSWORD 等管教語句來做的話，那麼無論如何都批准 SBR 形式登記
注：批准 RBR 形式後，能處理許多本來揭示的主鍵重複問題例如Pro Publica，SunlightFoundation和維基解密，開始添補鞭策媒體滑坡留下的空白。
MYSQL5.5MySQL 5.5 中對於二進制日誌 (binlog) 有 3 種不同的格式可選：Mixed,Statement,Row，默認格式是 Statement。總結一下這三種格式日誌的優缺點。
MySQL Replication 複製可以是基於一條語句 (Statement Level) ，也可以是基於一條記錄 (Row Level)，可以在 MySQL 的配置參數中設定這個複製級別，不同複製級別的設置會影響到 Master 端的 bin-log 日誌格式。
- 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 之類的表結構變更語句的處理方式是整個表的每一條記錄都需要變動，實際上就是重建了整個表。那麼該表的每一條記錄都會被記錄到日誌中。
- 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 是基於每一行來記錄的變化，所以不會出現類似的問題。
- 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 模式後，能處理很多原先出現的主鍵重複問題；
