set global read only 0 关闭只读 可以读写 set global read only 1 开始

本文详细介绍了如何在MySQL中设置全局只读模式,通过简单的SQL命令,可以在不影响现有数据的情况下,将数据库切换到只读状态,这对于维护和备份操作非常有用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.youkuaiyun.com/jiangjunshow

也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!

               
mysql> set global read_only=0;Query OK, 0 rows affected (0.00 sec)mysql> show variables like '%read_only%';+------------------+-------+| Variable_name    | Value |+------------------+-------+| innodb_read_only | OFF   || read_only        | OFF   || tx_read_only     | OFF   |+------------------+-------+3 rows in set (0.00 sec)mysql> set global read_only=1;Query OK, 0 rows affected (0.00 sec)mysql> show variables like '%read_only%';+------------------+-------+| Variable_name    | Value |+------------------+-------+| innodb_read_only | OFF   || read_only        | ON    || tx_read_only     | OFF   |+------------------+-------+3 rows in set (0.00 sec)set global read_only=0;  关闭只读,可以读写 set global read_only=1; 开始只读模式

           

给我老师的人工智能教程打call!http://blog.youkuaiyun.com/jiangjunshow
这里写图片描述
<think>我们正在解决两个问题:1.理解`master_accept_reads=true`参数的含义2.解决MaxScale报错`--read-only`的问题根据引用内容,我们可以得到以下信息:关于`master_accept_reads`:-引用[4]提到,MaxScale使用监控模块(如Multi-MasterMonitor或mysqlmon)通过`read_only`参数来选举Master和Slave。-参数`master_accept_reads`属于readwritesplit路由模块,它控制是否允许将读请求发送到主节点(Master)。关于`--read-only`报错:-这个报错通常发生在尝试向只读节点(Slave)写入数据时,或者当MaxScale的路由规则配置为只读而客户端尝试写操作时。-引用[1]提到,当主节点不可用时,MaxScale有几种处理方式,其中`fail_on_write`和`error_on_write`都会导致写操作失败(报错或断开连接)。同时,引用[4]提到,在故障转移时,通过脚本可以取消Slave的`read_only`属性,将其提升为Master。因此,我们需要分两部分来回答:第一部分:`master_accept_reads=true`参数含义-该参数默认值为true,表示允许将读请求发送到主节点。当设置为false时,读请求只会被发送到从节点(即使主节点可用)。第二部分:解决`--read-only`报错-这个报错可能是由于以下原因:a.客户端尝试写操作,但后端数据库节点(被当作从节点)是只读的。b.主节点故障后,从节点尚未提升为主节点(即其`read_only`仍然为ON),而此时写请求被路由到了该从节点。c.MaxScale的监控模块未能正确检测到主节点故障并进行故障转移。解决方案:1.检查后端数据库的只读状态:-确保主节点的`read_only`为OFF,从节点的`read_only`为ON。2.检查MaxScale的监控模块配置:-确保监控模块(如`mariadbmon`)正确配置,能够自动处理故障转移(即当主节点宕机时,将一个从节点提升为主节点,并将其`read_only`设为OFF)。-引用[4]提到,可以通过脚本实现故障转移时取消从节点的只读属性。3.检查读写分离路由的配置:-确保写请求只被发送到主节点。如果`master_accept_reads=false`,那么读请求不会发送到主节点,但写请求仍然会发送到主节点。4.检查主节点是否可用:-如果主节点不可用,而MaxScale的配置中处理写请求的方式是`error_on_write`,那么写操作会报错。根据引用[1],可以调整`master_failure_mode`参数(例如设置为`fail_instantly`或`fail_on_write`)来改变行为。5.检查客户端连接:-确保客户端没有直接连接到从节点(如果配置了多个服务,注意连接的是读写服务)。具体步骤:一、`master_accept_reads`参数详解-该参数用于readwritesplit路由服务,决定是否将读请求发送到主节点。-当设置为`true`时,在以下情况下读请求会被发送到主节点:*所有从节点都不可用*从节点延迟超过`max_slave_replication_lag`设置的值*在事务中(为了读取最新数据)-当设置为`false`时,读请求永远不会发送到主节点,即使所有从节点都不可用,读请求也会失败。二、解决`--read-only`报错-步骤1:检查后端数据库状态登录主节点和从节点,执行:```sqlSHOWVARIABLESLIKE'read_only';```主节点应为`OFF`,从节点应为`ON`。-步骤2:检查监控模块的故障转移功能在MaxScale的配置文件中,监控模块(如`mariadbmon`)应该配置了自动故障转移。例如:```ini[MySQL-Monitor]type=monitormodule=mariadbmonservers=server1,server2,server3user=myuserpassword=mypwdauto_failover=trueauto_rejoin=true```确保监控模块能够正确执行`SETGLOBALread_only=OFF`来提升从节点为主节点。-步骤3:检查读写分离服务的配置在读写分离服务中,确保写请求路由到主节点。例如:```ini[Read-Write-Service]type=servicerouter=readwritesplitservers=server1,server2,server3master_accept_reads=true```同时,检查`master_failure_mode`参数(引用[1]):```inimaster_failure_mode=fail_on_write```该参数决定了当主节点不可用时,对写请求的处理方式。如果设置为`error_on_write`,那么写请求会直接报错(可能包含read-only错误)。-步骤4:调整故障处理模式如果希望在主节点故障时,让写请求失败(而不是报错),可以设置:```inimaster_failure_mode=fail_on_write```这样,当主节点不可用时,写请求会立即失败(连接断开),而读请求仍然可以发送到从节点。-步骤5:确保监控模块的脚本正确如果使用脚本进行故障转移(如引用[4]所述),确保脚本有执行权限,并且逻辑正确(能够将提升的从节点的`read_only`设置为OFF)。-步骤6:检查客户端连接的服务确保客户端连接的是读写服务(Read-Write-Service)而不是只读服务(如果有配置只读服务)。三、其他可能的原因-如果使用了Galera集群,可能需要使用`galeramon`监控模块,并且注意Galera集群中所有节点默认都是可写的(但MaxScale的读写分离路由仍然会通过`read_only`来区分)。根据引用[4],在Multi-Master监控模块中,是通过`read_only`来选举Master的。因此,确保在故障转移后,新的主节点的`read_only`被正确设置为OFF。总结:参数`master_accept_reads=true`允许读请求发送到主节点,这可以确保当从节点不可用或延迟过高时,读请求仍然可以被处理。而`--read-only`报错通常是由于写请求被发送到了只读节点(从节点)导致的。解决的关键在于:-确保主节点可用且非只读-确保监控模块能够正确进行故障转移(将新的主节点设置为可写)-检查`master_failure_mode`的配置,避免写请求在错误情况下被路由到从节点最后,提供一个配置示例:在MaxScale的配置文件(/etc/maxscale.cnf)中:```ini[server1]type=serveraddress=192.168.1.1port=3306[server2]type=serveraddress=192.168.1.2port=3306[server3]type=serveraddress=192.168.1.3port=3306[MySQL-Monitor]type=monitormodule=mariadbmonservers=server1,server2,server3user=maxscalepassword=123456monitor_interval=2000msauto_failover=trueauto_rejoin=true[Read-Write-Service]type=servicerouter=readwritesplitservers=server1,server2,server3user=maxscalepassword=123456master_accept_reads=truemaster_failure_mode=fail_on_write[Read-Write-Listener]type=listenerservice=Read-Write-Serviceprotocol=MySQLClientport=4006```注意:确保监控模块使用的用户(maxscale)在MariaDB中有足够的权限执行`SHOWSLAVESTATUS`和`SETGLOBALread_only=ON|OFF`等操作。如果问题仍然存在,可以检查MaxScale的日志(默认在/var/log/maxscale/maxscale.log)以获取更详细的错误信息。相关问题:1.如何配置`mariadbmon`监控模块以实现自动故障转移?2.MaxScale的`master_failure_mode`参数有哪些可选值?各有什么作用?3.在MaxScale中,如何监控后端数据库的复制延迟?请根据上述思路组织答案。</think>### MaxScale `master_accept_reads=true` 参数详解及 `--read-only` 报错解决方案 #### 一、`master_accept_reads=true` 参数解析 该参数属于 MaxScale 的 `readwritesplit` 路由模块,**控制主节点是否接受读请求**: ```ini [ReadWrite-Service] type=service router=readwritesplit master_accept_reads=true # 核心参数 ``` | 参数值 | 行为表现 | 适用场景 | |--------|----------|----------| | `true` (默认) | 允许读请求发送到主节点 | 从节点延迟高时保证读取最新数据 | | `false` | 强制所有读请求仅发送到从节点 | 严格读写分离,减轻主节点压力 | **关键特性**: 1. **自动降级机制** - 当从节点不可用或延迟超过 `max_slave_replication_lag` 时 - 事务中的查询(需读取最新提交数据) - 会自动将读请求路由到主节点 2. **与监控模块协同** 通过监控模块(如 `mariadbmon`)检测后端节点的 `read_only` 状态[^4]: ```sql SHOW VARIABLES LIKE 'read_only'; -- 主节点应为OFF,从节点为ON ``` #### 二、`--read-only` 报错原因及解决方案 **报错场景**: ```bash ERROR 1290 (HY000): The MariaDB server is running with the --read-only option ``` ##### 根本原因分析 1. **后端节点状态异常** - 主节点意外设置为 `read_only=ON` - 从节点未正确设置 `read_only=ON`,导致写请求误路由 2. **故障转移未完成** - 主节点故障后,监控模块未及时提升新主节点[^4] - 新主节点的 `read_only` 未设置为 `OFF` 3. **路由配置冲突** - `master_accept_reads=false` 但主节点是唯一可用节点 - 写请求被错误路由到从节点 ##### 解决方案 **步骤1:验证后端节点状态** ```sql -- 在主节点执行 SHOW VARIABLES LIKE 'read_only'; -- 必须返回 OFF -- 在从节点执行 SHOW VARIABLES LIKE 'read_only'; -- 必须返回 ON ``` **步骤2:配置自动故障转移** ```ini [MySQL-Monitor] type=monitor module=mariadbmon servers=master,slave1,slave2 auto_failover=true # 启用自动故障转移 auto_rejoin=true # 允许节点恢复后重新加入 failover_timeout=30s # 故障转移超时[^1] ``` **步骤3:优化读写分离配置** ```ini [ReadWrite-Service] router=readwritesplit master_accept_reads=true # 确保允许主节点处理请求 master_failure_mode=fail_on_write # 主故障时写请求失败[^1] strict_mode=false # 允许临时降级到从节点 ``` **步骤4:修复节点状态脚本** 创建故障转移脚本(如 `promote_node.sh`): ```bash #!/bin/bash # 提升新主节点 mysql -h $1 -e "SET GLOBAL read_only=OFF;" # 通知MaxScale更新路由 maxctrl alter server $2 master ``` 配置监控模块调用脚本: ```ini [MySQL-Monitor] script=/path/to/promote_node.sh ``` **步骤5:验证连接路由** ```bash # 通过MaxScale连接测试写操作 mysql -h maxscale_host -P 4006 -e "INSERT INTO test.tb VALUES(1);" ``` #### 三、最佳实践建议 1. **监控配置** ```ini [MySQL-Monitor] monitor_interval=2000ms # 监控频率 replication_user=repl_user # 复制账号 replication_password=xxxx # 复制密码 ``` 2. **连接池管理** ```ini [server1] type=server connection_keepalive=300s # 连接保活[^2] max_connections=500 # 最大连接数 ``` 3. **日志诊断** 查看 MaxScale 错误日志定位问题: ```bash tail -f /var/log/maxscale/maxscale.log | grep -i 'read-only' ``` > **关键提示**:Galera 集群环境中,建议配合 `wsrep` 状态检测[^4]: > ```ini > [Galera-Monitor] > module=galeramon > disable_master_failback=true > ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值