首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

mysql主从 从库只读

基础概念

MySQL主从复制是一种数据库复制技术,它允许一个MySQL数据库(主库)的数据被复制到一个或多个其他MySQL数据库(从库)。从库默认是只读的,这意味着在从库上执行的写操作(如INSERT、UPDATE、DELETE)会被拒绝。

优势

  1. 读写分离:主库负责写操作,从库负责读操作,可以提高系统的读取性能。
  2. 数据备份:从库可以作为数据备份,防止主库数据丢失。
  3. 高可用性:当主库出现故障时,可以快速切换到从库,保证系统的可用性。
  4. 负载均衡:通过多个从库分担读取压力,提高系统的整体性能。

类型

MySQL主从复制主要有以下几种类型:

  1. 异步复制:主库在执行完写操作后立即返回,不等待从库确认。这是MySQL默认的复制方式。
  2. 半同步复制:主库在执行完写操作后需要等待至少一个从库确认收到数据后才返回。
  3. 组复制:多个MySQL实例组成一个复制组,数据在组内同步复制。

应用场景

  1. 高并发读取:适用于需要处理大量读取请求的应用,如电商网站、社交媒体等。
  2. 数据备份和恢复:通过从库进行数据备份,可以在主库故障时快速恢复数据。
  3. 高可用性架构:通过主从复制实现数据库的高可用性,保证系统在主库故障时仍能正常运行。

为什么从库是只读的?

从库默认是只读的,主要是为了防止从库上的数据被意外修改,从而保证数据的一致性。如果从库允许写操作,可能会导致主从数据不一致的问题。

如何解决从库只读的问题?

如果确实需要在从库上执行写操作,可以通过以下几种方式解决:

  1. 修改从库配置:可以通过修改从库的配置文件,将read_only参数设置为0,使从库变为可写。但这种方式会带来数据一致性的风险,不推荐在生产环境中使用。
  2. 使用中间件:可以使用一些数据库中间件,如MyCAT、MaxScale等,这些中间件可以在应用层实现读写分离,同时允许在从库上执行特定的写操作。
  3. 使用Galera Cluster:Galera Cluster是一种多主复制方案,所有节点都可以进行读写操作,并且保证数据的一致性。

示例代码

以下是一个简单的MySQL主从复制配置示例:

主库配置(my.cnf)

代码语言:txt
复制
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = mydatabase

从库配置(my.cnf)

代码语言:txt
复制
[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = mydatabase
read_only = 1

主库创建复制用户

代码语言:txt
复制
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

从库设置主库信息

代码语言:txt
复制
CHANGE MASTER TO
MASTER_HOST='master_host',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=107;
START SLAVE;

参考链接

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 【数据库智能管家DBbrain】MySQL复制延迟从原理到案例分析

    在数据库运维过程中,很多问题都需要靠人力来及时发现和处理,我之前也是一名DBA,可以说我做DBA的那段时间基本没有拥有过完整的属于自己的休息时间,全天候Online。现在AI技术已经广泛运用到了各个领域,数据库运维其实也是同样的,AI可以成为DBA的得力助手,有问题第一时间告警,甚至给出成熟的解决方案,DBA可以用更多的时间去完成高阶的任务。我现在主要负责的产品是DBbrian,是腾讯云推出的一款数据库智能运维工具。今天就以咱们MySQL运维过程中典型的主从延时故障来作为案例,告诉大家可以如何借助智能运维服务更好的发现和解决这类问题。

    04

    MySQL复制性能优化和常见问题分析

    二进制日志文件并不是每次写的时候都会同步到磁盘,当发生宕机的时候,可能会有最后一部分数据没有写入到binlog中,这给恢复和复制带来了问题。当sync_binlog=1表示每写缓冲一次就同步到磁盘,表示同步写磁盘的方式来写binlog。也就是说每当向MySQL提交一次事务,MySQL将进行一次fsync之类的磁盘同步命令来将binlog_cache的数据强制刷到磁盘中sync_binlog的值默认为0,sync_binlog=0时表示采用操作系统机制进行缓冲数据同步。采用sync_binlog=1时,会增加磁盘IO的次数,会影响写入性能。sync_binlog=1时,并不是100%安全,会存在相应的问题。比如说使用Innodb引擎时,在一个事务发出commit前,会将binlog立即刷到磁盘中。如果这时候已经写入到binlog中,但是还没有提交就已经挂了,那么MySQL重启时,会将通过Redo log、Undo log将这个事务回滚掉,但是binlog已经记入了该事务信息,不能回滚掉。所以我们需要设置innodb_support_xa=1确保MySQL服务层的binlog和MySQL存储引擎层的Redo log、Undo log之间的数据一致性。

    02
    领券