mysql salve从库设置read only 属性

本文介绍了MySQL数据库中只读模式的设置方法,包括如何通过设置read_only参数来限制普通用户的写入操作,以及如何利用表锁确保超级用户也无法更改数据。

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

在MySQL数据库中,在进行数据迁移和从库只读状态设置时,都会涉及到只读状态和Master-slave的设置和关系。
 
 
经过实际测试,对于MySQL单实例数据库和master库,如果需要设置为只读状态,需要进行如下操作和设置:
将MySQL设置为只读状态的命令:
# mysql -uroot -p
mysql> show global variables like "%read_only%";
mysql> flush tables with read lock;
mysql> set global read_only=1;
mysql> show global variables like "%read_only%";
 
 
将MySQL从只读设置为读写状态的命令:
mysql> unlock tables;
mysql> set global read_only=0;
 
 
对于需要保证master-slave主从同步的salve库,如果要设置为只读状态,需要执行的命令为:
mysql> set global read_only=1;
 
 
将salve库从只读状态变为读写状态,需要执行的命令是:
mysql> set global read_only=0;
 
 
     对于数据库读写状态,主要靠 “read_only”全局参数来设定;默认情况下,数据库是用于读写操作的,所以read_only参数也是0或faluse状态,这时候不论是本地用户还是远程访问数据库的用户,都可以进行读写操作;如需设置为只读状态,将该read_only参数设置为1或TRUE状态,但设置 read_only=1 状态有两个需要注意的地方:
      1.read_only=1只读模式,不会影响slave同步复制的功能,所以在MySQL slave库中设定了read_only=1后,通过 show slave status\G 命令查看salve状态,可以看到salve仍然会读取master上的日志,并且在slave库中应用日志,保证主从数据库同步一致;
      2.read_only=1只读模式,可以限定普通用户进行数据修改的操作,但不会限定具有super权限的用户的数据修改操作;在MySQL中设置read_only=1后,普通的应用用户进行insert、update、delete等会产生数据变化的DML操作时,都会报出数据库处于只读模式不能发生数据变化的错误,但具有super权限的用户,例如在本地或远程通过root用户登录到数据库,还是可以进行数据变化的DML操作;
-------锁表---
      为了确保所有用户,包括具有super权限的用户也不能进行读写操作,就需要执行给所有的表加读锁的命令 “flush tables with read lock;”,这样使用具有super权限的用户登录数据库,想要发生数据变化的操作时,也会提示表被锁定不能修改的报错。
 
        这样通过 设置“read_only=1”和“flush tables with read lock;”两条命令,就可以确保数据库处于只读模式,不会发生任何数据改变,在MySQL进行数据库迁移时,限定master主库不能有任何数据变化,就可以通过这种方式来设定。
 
       但同时由于加表锁的命令对数据库表限定非常严格,如果再slave从库上执行这个命令后,slave库可以从master读取binlog日志,但不能够应用日志,slave库不能发生数据改变,当然也不能够实现主从同步了,这时如果使用 “unlock tables;”解除全局的表读锁,slave就会应用从master读取到的binlog日志,继续保证主从库数据库一致同步。
 
       为了保证主从同步可以一直进行,在slave库上要保证具有super权限的root等用户只能在本地登录,不会发生数据变化,其他远程连接的应用用户只按需分配为select,insert,update,delete等权限,保证没有super权限,则只需要将salve设定“read_only=1”模式,即可保证主从同步,又可以实现从库只读。
 
 
       相对的,设定“read_only=1”只读模式开启的解锁命令为设定“read_only=0”;设定全局锁“flush tables with read lock;”,对应的解锁模式命令为:“unlock tables;”.
 
      当然设定了read_only=1后,所有的select查询操作都是可以正常进行的。
<think>好的,用户现在想了解如何在MySQL 8.4中重启Slave。首先,我需要确认MySQL的版本,因为用户提到的是8.4,而实际上官方最新的稳定版本是8.0.x,可能用户有笔误或者获取的信息有误。不过不管怎样,处理Slave重启的步骤在大多数版本中应该是类似的。 接下来,用户可能是在进行主从复制时遇到了问题,需要重启Slave服务来解决问题。常见的情况可能是复制中断,需要重新启动复制进程,或者修改了配置后需要重新加载。用户可能有不同的操作环境,但根据之前的对话历史,用户是在CentOS 9上配置集群,所以应该是在Linux环境下使用命令行操作。 首先,我需要回顾如何在MySQL中管理Slave复制。基本的步骤包括停止Slave、进行必要的修改或修复,然后重新启动Slave。常用的命令有STOP SLAVE;和START SLAVE;,以及查看状态的SHOW SLAVE STATUS\G;。 但需要注意,MySQL 8.0之后,术语有所变化,官方推荐使用更中性的术语,比如将Master改为Source,Slave改为Replica。因此,在MySQL 8.0及以上版本中,建议使用START REPLICA;而不是START SLAVE;,但旧命令仍然有效。用户可能对旧命令更熟悉,所以需要说明新旧两种方式,并指出兼容性问题。 另外,重启Slave可能涉及到不同的场景:比如单纯的停止和启动,或者需要重置复制位置,或者修改配置后的重启。用户可能没有说明具体情况,所以需要分情况讨论,给出不同的方法。 还需要考虑用户是否有权限执行这些操作,必须确保用户有足够的权限运行这些命令,通常需要REPLICATION SLAVE权限。另外,在重启Slave之前,可能需要解决导致复制停止的错误,比如主键冲突、网络问题等,否则单纯重启可能无法解决问题,复制可能会再次停止。 此外,用户可能对如何确认Slave的状态不太清楚,需要指导他们使用SHOW REPLICA STATUS;或者SHOW SLAVE STATUS;来查看当前的复制状态,确认是否有错误信息,以及复制是否正常进行。 最后,可能需要提醒用户在修改配置后,是否需要重启MySQL服务,还是只需要重启复制线程。例如,如果更改了my.cnf中的配置,可能需要重启MySQL服务,而不仅仅是复制进程。但如果是动态变量,可以用SET GLOBAL来调整,无需重启服务。 总结下来,回答应该包括以下几个步骤: 1. 停止复制进程。 2. 进行必要的修复或配置更改。 3. 重新启动复制进程。 4. 检查复制状态。 同时,需要说明新旧命令的区别,权限要求,以及常见问题处理建议。</think>### MySQL 8.4 中重启 Slave 的步骤 (注:MySQL 官方文档中已逐步将 `SLAVE` 术语更新为 `REPLICA`,以下命令均兼容 MySQL 8.0+ 版本) --- #### **一、基本操作流程** 1. **停止复制进程** 在 MySQL 命令行中执行: ```sql STOP REPLICA; -- 新语法(推荐) -- 或旧语法(兼容) STOP SLAVE; ``` 2. **检查复制状态** 确认线程已停止: ```sql SHOW REPLICA STATUS\G; -- 新语法 -- 或 SHOW SLAVE STATUS\G; -- 旧语法 ``` ✅ 观察 `Replica_IO_Running` 和 `Replica_SQL_Running` 是否为 `No`。 3. **重启复制进程** ```sql START REPLICA; -- 新语法(推荐) -- 或旧语法(兼容) START SLAVE; ``` 4. **验证运行状态** ```sql SHOW REPLICA STATUS\G; ``` ✅ 确保 `Replica_IO_Running` 和 `Replica_SQL_Running` 恢复为 `Yes`,且 `Last_IO_Error`/`Last_SQL_Error` 无报错。 --- #### **二、特殊场景处理** 1. **需重置复制位置** 若需重新同步数据(例如主从数据不一致): ```sql STOP REPLICA; RESET REPLICA ALL; -- 清除所有复制配置(8.0.22+) -- 或旧版本语法 RESET SLAVE ALL; -- 重新配置复制链路 CHANGE REPLICATION SOURCE TO SOURCE_HOST='主节点IP', SOURCE_USER='replica_user', SOURCE_PASSWORD='password', SOURCE_PORT=3306, SOURCE_AUTO_POSITION=1; -- 使用GTID自动定位 START REPLICA; ``` 2. **跳过临时错误** 若因事务冲突需跳过错误(谨慎使用): ```sql STOP REPLICA; SET GLOBAL SQL_REPLICA_SKIP_COUNTER=1; -- 跳过1个事件 START REPLICA; ``` --- #### **三、注意事项** 1. **权限要求** - 操作需用户具有 `REPLICATION SLAVE` 权限。 - 若使用旧语法(`SLAVE`),需确保 MySQL 版本兼容性。 2. **错误排查** - 若重启后仍报错,检查 `Last_IO_Error` 和 `Last_SQL_Error` 字段,常见问题: - 主从网络不通 - 主节点二进制日志被清理 - 主从用户权限失效 3. **配置文件修改** - 若修改了 `my.cnf` 中的复制参数(如 `server_id`),需重启 MySQL 服务生效: ```bash systemctl restart mysqld ``` --- #### **四、操作示例** ```sql -- 停止复制 STOP REPLICA; -- 重置复制链路(可选) RESET REPLICA ALL; -- 重新配置主节点信息 CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.100', SOURCE_USER='replica_user', SOURCE_PASSWORD='SecurePass123!', SOURCE_AUTO_POSITION=1; -- 启动复制 START REPLICA; -- 验证状态 SHOW REPLICA STATUS\G; ``` 如需进一步解决具体错误场景(如 GTID 不一致、主键冲突等),请提供详细错误日志。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值