双M结构中，从库提供read服务,单独创建用户的时候建议不写入binlog日志

从库提供read服务,单独创建用户的时候建议不写入binlog日志

在当前client连接的sessiion中，执行操作的时候，关闭二进制日志，这样下面的所有ddl以及dml操作sql不会写入到binlog中，也不会被同步到slave中。

set sql_log_bin =0;

授予访问权限
GRANT select ON cart.* TO 'xxxx'@'xxxxxx;

这样就不会影响正在运行的主库了，请看如下文档介绍

sql_log_bin

If set to 0, no logging is done to the binary log for the client. The client must have theSUPER privilege to set this option. The default value is 1.

Beginning with MySQL 5.5.5, it is no longer possible to set @@session.sql_log_bin within a transaction or subquery. (Bug#53437)

再看另外一个类似的参数

sync_binlog

“sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

请看官方文档：

sync_binlog

Command-Line Format	--sync-binlog=#
Config-File Format	sync_binlog
Option Sets Variable	Yes, sync_binlog
Variable Name	sync_binlog
Variable Scope	Global
Dynamic Variable	Yes
	Permitted Values
	Platform Bit Size	32
	Type	numeric
	Default	0
	Range	0-4294967295
	Permitted Values
	Platform Bit Size	64
	Type	numeric
	Default	0
	Range	0-18446744073709547520

If the value of this variable is greater than 0, the MySQL server synchronizes its binary log to disk (usingfdatasync()) after everysync_binlog writes to the binary log. There is one write to the binary log per statement if autocommit is enabled, and one write per transaction otherwise. The default value ofsync_binlog is 0, which does no synchronizing to disk—in this case, the server relies on the operating system to flush the binary log's contents from to time as for any other file. A value of 1 is the safest choice because in the event of a crash you lose at most one statement or transaction from the binary log. However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).