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

mysql中的主库和次库

基础概念

MySQL中的主库(Master)和次库(Slave)是一种常见的数据库复制架构,用于实现数据的冗余和高可用性。在这种架构中,主库负责处理所有的写操作(如INSERT、UPDATE、DELETE),而次库则负责处理读操作(如SELECT)。主库会将所有的数据变更操作记录到二进制日志(Binary Log)中,次库通过复制这些日志来同步主库的数据。

相关优势

  1. 高可用性:当主库发生故障时,可以快速切换到次库,保证服务的连续性。
  2. 负载均衡:通过将读操作分散到多个次库上,可以有效减轻主库的负载,提高系统的整体性能。
  3. 数据备份:次库可以作为数据的备份,防止数据丢失。

类型

  1. 异步复制:主库在执行完写操作后立即返回结果,不等待次库确认。这种方式的优点是性能高,但缺点是可能存在数据不一致的情况。
  2. 半同步复制:主库在执行完写操作后需要等待至少一个次库确认收到日志,然后再返回结果。这种方式可以减少数据不一致的风险,但会稍微降低性能。
  3. 同步复制:主库在执行完写操作后需要等待所有次库确认收到日志,然后再返回结果。这种方式可以最大程度地保证数据一致性,但性能最低。

应用场景

  1. 读写分离:将读操作和写操作分别分配到不同的数据库实例上,提高系统的整体性能。
  2. 数据备份和恢复:通过次库进行数据备份,当主库发生故障时,可以快速切换到次库,保证数据的可用性。
  3. 分布式系统:在分布式系统中,通过主从复制可以实现数据的冗余和高可用性。

常见问题及解决方法

  1. 数据不一致
    • 原因:异步复制可能导致数据不一致。
    • 解决方法:使用半同步复制或同步复制来减少数据不一致的风险。
  • 复制延迟
    • 原因:网络延迟、次库性能不足等原因可能导致复制延迟。
    • 解决方法:优化网络环境,提升次库的性能,或者增加次库的数量来分担负载。
  • 主库故障
    • 原因:硬件故障、软件错误等原因可能导致主库故障。
    • 解决方法:配置主从切换机制,当主库发生故障时,自动切换到次库。

示例代码

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

主库配置(my.cnf)

代码语言:txt
复制
[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW

次库配置(my.cnf)

代码语言:txt
复制
[mysqld]
server-id=2
relay-log=mysql-relay-bin
log-slave-updates=1
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;

参考链接

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

相关·内容

MySQL 主库跑太快,从追不上怎么整?

作者|莱乌 写这篇文章是因为之前有一操作,需要进行批量删除数据,当时没有控制好删除速度,导致产生了主从延迟,出现了一点小事故。...但是问题就来了,读从数据要与主库保持一致,那就需要主库数据在写入后同步到从。如何保持主库与从数据一致性,主库又是通过什么样方式将数据实时同步到从?...随机重放 Mysql 主库写 binlog 操作是顺序写,之前我们提到过,磁盘顺序读写速度是很快。同样,从 I/O 线程操作日志速度效率也是很高。...主库并发高 知道了从 SQL 线程重放情况,对于主库并发高导致主从延迟肯定就不难理解了。...总结 主从复制原理 主从复制中有两个很重要日志文件,binlogrelay log,分别位于主库与从

1.4K20

Mysql 主库跑太快,从追不上怎么整?

写这篇文章是因为之前有一操作,需要进行批量删除数据,当时没有控制好删除速度,导致产生了主从延迟,出现了一点小事故。 今天我们就来看看为什么会产生主从延迟以及主从延迟如何处理等相关问题。...但是问题就来了,读从数据要与主库保持一致,那就需要主库数据在写入后同步到从。如何保持主库与从数据一致性,主库又是通过什么样方式将数据实时同步到从?...基本原理 Mysql 主从复制时有两个很重要日志文件: binlog(二进制日志文件) relay log(中继日志文件) 在主从同步过程主库会将所有的操作事件记录在 binlog ,从通过开启一个...随机重放 Mysql 主库写 binlog 操作是顺序写,之前我们提到过,磁盘顺序读写速度是很快。同样,从 I/O 线程操作日志速度效率也是很高。...总结 主从复制原理 主从复制中有两个很重要日志文件,binlogrelay log,分别位于主库与从

1.2K30
  • MySQL 主库跑太快,从追不上怎么整?

    来自:莱乌 写这篇文章是因为之前有一操作,需要进行批量删除数据,当时没有控制好删除速度,导致产生了主从延迟,出现了一点小事故。...但是问题就来了,读从数据要与主库保持一致,那就需要主库数据在写入后同步到从。如何保持主库与从数据一致性,主库又是通过什么样方式将数据实时同步到从?...基本原理 Mysql 主从复制时有两个很重要日志文件: binlog(二进制日志文件) relay log(中继日志文件) ?...随机重放 Mysql 主库写 binlog 操作是顺序写,之前我们提到过,磁盘顺序读写速度是很快。同样,从 I/O 线程操作日志速度效率也是很高。...总结 主从复制原理 主从复制中有两个很重要日志文件,binlogrelay log,分别位于主库与从

    1.4K31

    面试官:Mysql 主库跑太快,从追不上怎么整?

    作者|莱乌 写这篇文章是因为之前有一操作,需要进行批量删除数据,当时没有控制好删除速度,导致产生了主从延迟,出现了一点小事故。...但是问题就来了,读从数据要与主库保持一致,那就需要主库数据在写入后同步到从。如何保持主库与从数据一致性,主库又是通过什么样方式将数据实时同步到从?...基本原理 Mysql 主从复制时有两个很重要日志文件: binlog(二进制日志文件) relay log(中继日志文件) ?...随机重放 Mysql 主库写 binlog 操作是顺序写,之前我们提到过,磁盘顺序读写速度是很快。同样,从 I/O 线程操作日志速度效率也是很高。...总结 主从复制原理 主从复制中有两个很重要日志文件,binlogrelay log,分别位于主库与从

    61920

    面试官:Mysql 主库跑太快,从追不上怎么整?

    作者|莱乌 写这篇文章是因为之前有一操作,需要进行批量删除数据,当时没有控制好删除速度,导致产生了主从延迟,出现了一点小事故。...但是问题就来了,读从数据要与主库保持一致,那就需要主库数据在写入后同步到从。如何保持主库与从数据一致性,主库又是通过什么样方式将数据实时同步到从?...基本原理 Mysql 主从复制时有两个很重要日志文件: binlog(二进制日志文件) relay log(中继日志文件) ?...随机重放 Mysql 主库写 binlog 操作是顺序写,之前我们提到过,磁盘顺序读写速度是很快。同样,从 I/O 线程操作日志速度效率也是很高。...总结 主从复制原理 主从复制中有两个很重要日志文件,binlogrelay log,分别位于主库与从

    81120

    Mysql主库跑太快,从追不上怎么做?

    写这篇文章是因为之前有一操作,需要进行批量删除数据,当时没有控制好删除速度,导致产生了主从延迟,出现了一点小事故。 ? 主从常见架构 随着日益增长访问量,单台数据应接能力已经捉襟见肘。...同时通过从进行水平扩展使系统伸缩性及负载能力也得到了很大提升。 ? 但是问题就来了,读从数据要与主库保持一致,那就需要主库数据在写入后同步到从。...在主从同步过程主库会将所有的操作事件记录在 binlog ,从通过开启一个 I/O 线程保持与主库通信,并在一定时间间隔内探测 binlog 日志文件是否发生改变。...随机重放 Mysql 主库写 binlog 操作是顺序写,之前我们提到过,磁盘顺序读写速度是很快。同样,从 I/O 线程操作日志速度效率也是很高。...总结 主从复制原理 主从复制中有两个很重要日志文件,binlogrelay log,分别位于主库与从

    1K50

    mysql SQL调优-主库查询比从还慢原因

    处理过程: 1、在从查看执行计划: ? 并且执行查询,结果是返回159条数据,只需要0.58秒,并不慢 ?...2、了解到原来应用连接主库,随即上主库查看执行计划,如下,可以看到执行计划是不一样,从性能没问题,而主库性能有问题,初步可以断定,就是统计信息不准确原因。...于是让开发先将连接修改到从,问题得到解决,接着继续分折统计信息不正确原因。 ?...(2)通过select count(1) from sy_paid_user_retained可以看到,发现表总记录数是2千多万,这能确认就是统计信息不准确原因,一开始认为表比较大,会不会是因为采样不准原因...(5)通过向开发了解,最近是有一个作业,执行了大量delete操作,我们从统计信息来看,应该有5000万delete。从不存在长事务,所以不存在这个问题。

    1.6K20

    mysql主库更新后,从都读到最新值了,主库还有可能读到旧值吗?

    mysql读写分离 虽然主库一般用于写操作,但也是能读。那么今天问题来了。 主库更新后,主库都读到最新值了,从还有可能读到旧值吗? 主库更新后,从都读到最新值了,主库还有可能读到旧值吗?...毕竟面试官都这么问了,那当然是有可能,那至于是为啥,以及怎么做到,今天我们来好好聊聊。 正常主从更新流程 比如我在主库都有张user表,此时有以下两条数据。...主库binlog dump线程 以上,主库工作就结束了,我们说说从。 从在收到binlog后,会有一个io线程负责把收到数据写入到relay log(中继日志)。...在这里relay log作用就类似于一个中间层,主库是多线程并发写,从sql线程是单线程串行执行,所以这两边生产消费速度肯定不同。...可以通过在从执行 show full processlist; 确认 io线程sql线程存在。 io线程sql线程 因此总结起来,主从同步步骤就是 1.执行更新sql语句。

    51620

    mysqldump过程主库做DDL会怎样?

    今天时间有点晚了,就写一个小知识点吧,在我们线上环境,大多都是采用主从复制架构,当我们在从使用mysqldump进行逻辑备份时候,如果此时主库有一个小DDL操作,那么我们在从上会看到什么现象...而由于MySQL中支持MVCC多版本控制协议,可以确保你在导出数据过程,其他DML语句是可以正常更新进表。 2、该参数避免了复制过程锁全表操作。...这里,假设我们主库上对table_1进行了DDL变更,新增了一个字段,那么从可能会发生下面的情况: 1、如果主库DDL操作在步骤4之前到达从,那么对mysqldump无影响 2、如果在时刻2到达...,此时mysqldump会停止,并且会报错:Table definition has changed, please retry transaction 3、如果在时刻2时刻3之间到达(也就是步骤5执行期间到达...),此时正在进行select * from table_1操作,mysqldump占用着表table_1元数据锁,也就是MDL锁,binlog会被阻塞,发生主从延迟 4、如果在步骤6之后开始,则MySQL

    1.2K20

    mysql主从报错1032 (主库都回放不了binlog就别为难从了)

    导读最近遇到一个mysql主从报错1032问题. 比较离谱.所以记录一下. 由于比较离谱, 这里没能复现出来(我是在5744上测试, 后面有机会再测试下5741), 所以没法给出相关截图....LOGICAL_CLOCKbinlog_rows_query_log_events = ON # 记录SQL方便问题排查.问题表无主键, 但有普通索引.问题主从报错 sql线程 1032 使用如下SQL查询具体报错位置表....000xxx --stop-position=xx | mysql然后查询出该表数据 做校验, 发现也是完全一致(md5行数都完全一样)....这就开始离谱了....主从数据完全一致, 主库产生binlog 从却执行不了. 于是就准备让主库自己去执行看下.继续回放主库binlog....也就是主库产生binlog, 主库自己都回放不了, 也就不怪从了. 解决办法解决起来还是比较简单, 就是加个主键就行.

    49810

    挽救DG主库nologging操作

    在一些场景,我们会去使用nologging操作去节省大量数据插入时间,而这种操作所带来问题就是,如果该在有备情况下,因为主库nologging插入操作不会生成redo,所以不会在备上传输应用...                     0 /data/data1/ORCL2/datafile/o1_mf_ax_3bt1e9nb_.dbf                       0 3、比较主数据备用数据查询结果...如果主库UNRECOVERABLE_CHANGE#列值大于备同一列,则需要将这些数据文件在备恢复。...DEMO SQL> select count(1) from demo;  COUNT(1) ----------    101000 对于这种情况,在12.1版本,RMAN提供了一种便捷方式让我们不需要在主库上进行数据文件备份传输而可以在备使用...而在12.2,Oracle提供了一种更方便方式去进行恢复主库会将未记录列表发送至备,并记录在备控制文件,我们可以从备v$nonlogged_block这个视图查看到相关信息。

    81760

    MYSQL 主库操作大表DDL ,从崩溃与系统参数错误设置

    事情是这样,一个用户测试UAT,从无故频繁报错 而内存本身是OK。...2 则是 1 反例,他提供内存分配仅仅会对整体系统50%进行分配, SWAP + 整体内存 50% 是他最多能分配,当无法对应用程序分配内存,系统并不会OOM应用,但应用会接受到一个内存分配错误...在修改后 在查看MYSQL 错误日志,,从修改后,系统目前也就没有错误了....后来其他DBA 想起来当初是为了测试这个参数对数据影响,而调整了参数....if (free > pages) // pages为需要分配内存大小,free为根据一定规则算出来“空闲内存大小”,第一free仅为NR_FILE_PAGES+NR_SLAB_RECLAIMABLE

    57630

    分别在MySQL5.78.0测试主从复制主库表缺失主键会导致主从延迟情况

    主从复制延迟,可能原因有主库方面: ① 主库写binlog不及时。...② dump线程压力大 ③ IO线程阻塞 ④ 表缺乏主键或唯一索引(常见) 假设主库更新一张500w表20w行数据,该update语句仅需要全表扫描1;而在row格式下,记录到binlog日志...SQL为20wupdate操作,此时SQL Thread重放将特别慢,因为每一update都需要进行一全表扫描,即从需要执行20w全表扫描。...由于没有主键索引,所以,就会导致在从进行2万全表扫描,这样也就拖慢了从APPLY效率。...2、从MySQL 8.0开始主从复制架构,若主库大表没有主键,仍然会导致从延迟,但是,延迟现象没有5.7那么严重,所以,我们仍然建议主库大表一定需要有主键。

    47730

    记录一实际过程MySql数据SQL优化

    前言 之前开发项目的过程当中数据库存储数据量都不是很大,在表设计当中就只有一个主键索引。很少接触到数据索引,SQL 优化这些东西。...网上关于索引文章很多,这里推荐一篇比较好文章:MySQL性能优化之索引优化 SQL优化也有对本身SQL代码优化。比如 not in exists这种。...SQL语句执行顺序 实际过程 理论是基础,在实际过程当中需要灵活运用。特此记录自己在进行优化时一些操作和心得。 查看执行语句选择索引,一查询只会选择一个索引,是mysql自动进行选择。...但是mysql并不会总是选择我们希望索引。所以要结合索引相关知识让mysql选择到我们希望索引。...---- 标题:记录一实际过程MySql数据SQL优化 作者:海加尔金鹰 地址:https://www.hjljy.cn/articles/2020/01/09/1578549162667

    87520

    MySQLMySQL数据密码加密查询解决方案

    : 一开始我还觉得是不是我插入sql语句写有问题,后来才知道在MySQL 8.0,PASSWORD()函数已被弃用。 ...于是又查了自己系统MySQL版本,发现果然是8.0以后版本。...二、解决方案 为了实现在MySQL数据中保存加密后密码,自己使用了AES_ENCRYPT(str,key)函数进行加密,在存入数据时候,转成十六进制。...解密函数 AES_DECRYPT(str,key),AES_DECRYPTAES_ENCRYPTkey要相同,解密之前先用huhex函数转一。...如果你只是想在MySQL查看解密后明文(假设明文是有效UTF-8),你可以尝试使用CONVERT()函数将二进制数据转换为字符类型,但这只有在解密后数据确实是有效字符编码时才会工作:  SELECT

    32910

    MySQL 双主单写,主库偶尔出现大量延迟原因

    作者:高鹏(网名八怪),《深入理解MySQL主从原理32讲》系列作者。...我们是双主单写,这里约定写入主库,没有写入为从。我们falcon偶尔会进行报警如下(频率很低): ?...关于更多延迟计算细节参考: https://www.jianshu.com/p/033f83314619 三、产生延迟原因 1.主库:首先主库写到从Event,从会写入到binlog(log_slave_updates...主库SQL线程平时并没有读取到Event,因为所有的Event都被IO线程过滤掉了。因此 Event headertimestamp 不会更新(MTS)。...但是如果从binlog切换时候,从至少会传送ROTATE_EVENT给主库,这个时候主库会拿到这个实际Event,因此Event headertimestamp 更新了。

    92410
    领券