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。总结一下这三种名目日志的优缺点。