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

本文深入探讨MySQL中的二进制日志(Binlog)功能,包括如何通过设置sql_log_bin参数来控制是否记录客户端操作到Binlog,以及sync_binlog参数对性能和数据完整性的关键影响。详细解释了不同sync_binlog值的含义,如sync_binlog=0与sync_binlog=1之间的性能差异。

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

 

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

set sql_log_bin =0;

 

授予访问权限

GRANT select ON cart.* TO 'xxxx'@'xxxxxx;

 

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

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).

  • 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

 

<think>嗯,用户询问的是关于MySQL主备架构的扩展问题——能否部署两个主和两个备。这个问题涉及到MySQL复制架构的设计选择,需要结合用户之前关注的引用内容来分析。 用户之前的对话中已经深入了解过单主单备的配置,现在显然在考虑更复杂的架构。从引用[1]可以看到主备复制能替代备份,引用[2][3]提到多源复制技术,引用[4]强调从只读的重要性,而引用[5]描述了主切换的复杂性——这些都需要在回答中融合。 注意到用户可能面临的实际需求:业务需要更高可用性,或者存在跨机房部署的需求?但用户目前尚未明确说明具体场景。考虑在回答中覆盖两种主流方案:从环形复制和主单从多源复制,同时提醒运维复杂度的问题。 关于技术可行性,根据MySQL官方文档,确实支持multi-source replication(5.7+)和multi-master replication。过引用[5]提到的orchestrator故障切换原则特别重要——延迟最低一定是最好选择,这点在主架构下更需注意。 准备在回答中强调几个关键点:数据冲突风险(需要业务层规避)、环形复制的脑裂风险、多源复制的性能影响。引用[4]中关于read_only的设定在主架构下会失效,这点也需要特别说明。 用户可能是运维人员或架构师,提问方式比较专业。考虑在最后补充两个实践性建议:使用GTID简化故障转移、推荐Percona工具监控环形复制延迟。相关问题的设计侧重实际运维痛点,比如监控方案和冲突解决。 需要特别注意数学表达式的格式要求:所有inline变量如$n$个节点要用$...$包裹,公式如$R_{sync}=\frac{N}{t}$单独成段。过当前问题涉及复杂公式,主要注意术语统一即可。 </think>是的,完全可以配置**两个主和两个备**,MySQL支持多种复制拓扑结构。以下是两种常见的实现方案及相关注意事项: --- ### 方案一:从环形复制(高冗余) ```mermaid graph LR A[主1] -->|复制| B[备1] B -->|复制| C[主2] C -->|复制| D[备2] D -->|复制| A ``` #### 配置要点: 1. **所有节点启用二进制日志** 修改所有节点的`my.cnf`: ```ini [mysqld] server-id=unique_num # 每个节点唯一 log-bin=mysql-bin # 所有节点开启binlog auto_increment_offset=1 # 主1设为1 auto_increment_increment=2 # 所有节点设为2 ``` > **自增ID配置**:避免写入冲突 > - 主1:`offset=1, increment=2` → 生成ID序列:1,3,5... > - 主2:`offset=2, increment=2` → 生成ID序列:2,4,6... [^4] 2. **建立环形复制链路** 在每个节点执行: ```sql CHANGE MASTER TO MASTER_HOST='next_node_ip', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_AUTO_POSITION=1; # 使用GTID简化管理 START SLAVE; ``` 3. **备设为只读**(关键!) ```ini # 备1/备2的my.cnf read_only=ON super_read_only=ON # 防止特权用户操作[^4] ``` --- ### 方案二:主 + 多源复制备(集中查询) ```mermaid graph TD A[主1] -->|复制| C[备] B[主2] -->|复制| C ``` #### 配置要点(MySQL 5.7+): 1. **备启用多源复制** ```sql -- 配置主1的复制通道 CHANGE MASTER TO MASTER_HOST='master1_ip', MASTER_USER='repl', MASTER_PASSWORD='pass', MASTER_LOG_FILE='binlog.0001', MASTER_LOG_POS=154 FOR CHANNEL 'master1_channel'; # 指定通道名[^3] -- 配置主2的复制通道 CHANGE MASTER TO ... FOR CHANNEL 'master2_channel'; START SLAVE FOR CHANNEL 'master1_channel'; START SLAVE FOR CHANNEL 'master2_channel'; ``` 2. **监控各通道状态** ```sql SHOW SLAVE STATUS FOR CHANNEL 'master1_channel'\G SHOW SLAVE STATUS FOR CHANNEL 'master2_channel'\G ``` --- ### ️ 关键注意事项 1. **数据冲突风险** - 主架构中,若同时修改同一条记录会导致复制中断 - 解决方案: - 业务层分片写入(如按用户ID哈希到同主) - 使用中间件(如ProxySQL)路由请求 2. **故障切换复杂度** - 环形复制中单点故障需手动重建链路 - 建议工具支持: ```bash orchestrator -c graceful-master-takeover -alias my-cluster ``` 引用[5]表明orchestrator可实现自动化切换 3. **一致性校验** 定期使用工具检查数据一致性: ```bash pt-table-checksum --replicate=percona.checksums ``` --- ### 两种方案对比 | **特性** | 环形复制 | 多源复制备 | |--------------------|--------------------------|--------------------------| | **写入节点** | 主(可同时写入) | 写入,备只读 | | **数据一致性** | 需避免冲突 | 各主独立,无冲突 | | **适用场景** | 高可用活 | 数据聚合分析 | | **运维复杂度** | 高(需处理冲突和脑裂) | 中(通道独立管理) | | **版本要求** | MySQL 5.6+ | MySQL 5.7+(多源复制) | > **推荐选择**: > - 需写入 → **环形复制** + 业务防冲突设计 > - 只需集中查询 → **多源复制备**(更简单稳定) ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值