- 综合排序
- 最热优先
- 最新优先
- 来自专栏立权的博客
Mysql 主备原理
Mysql 支持互为主从，主库通过binlog 将执行的语句传给从库，具体的执行机构： 主库上的 dump thread，主库上的 binlog 只有在写入到硬盘之后才能通过 dump thread 也就是 像 2 那样有歧义的话，就会使用 row 格式，而不是 statement 循环复制问题，前面提到，mysql 支持互为主从，那么 binlog 不会在 互为主从的两个数据库之间循环复制吗？
2.4K10发布于 2020-11-27 - 来自专栏云生产力
MySQL主备切换解析
MySQL主备切换解析MySQL的主备切换是高可用性数据库架构中的重要一环。通过主备切换，可以在主库出现故障时迅速切换到备库，从而保证系统的持续运行。 本文将详细解析MySQL主备切换的基本原理、实现方法以及相关的注意事项。一、MySQL主备基本原理在MySQL的主备架构中，通常有一个主库（Master）和一个或多个备库（Slave）。 Mixed格式：MySQL根据SQL语句是否可能引起主备不一致，自动选择使用statement或row格式。 三、主备切换实现方法实现MySQL主备自动切换，可以使用MySQL Replication和MySQL Cluster等工具。 MySQL在binlog中记录了命令第一次执行时的实例server id，通过比较server id来避免循环复制。四、主备切换策略主备切换策略主要分为可靠性优先策略和可用性优先策略。
1.5K00编辑于 2024-12-04 - 来自专栏凝神长老和他的朋友们
MySQL备份与主备配置
MySQL 主备配置 在主库上创建用户 repl，并给他权限。 主备延迟 最后需要说明的是，主备之间存在一个延迟。 主库 A 执行完成一个事务，写入 binlog，我们把这个时间记为 T1。 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2。 备库 B 执行完成这个事务，我们把这个时刻记为 T3。 主备延迟即 T3 - T1 的差。 这是因为，主备延迟的来源有： 备库的性能更差 备库压力较大 大事务 必须执行完才会写入 binlog，然后传给备库 在试验中并没有遇到这样的情况。 当然可以手动构造大量的数据来做个测试。 练习 2 尝试配置MySQL一主一备及双主结构。 上文已详述。
2.4K20发布于 2020-04-17 - 来自专栏shysh95
MySQL GTID主备切换协议
一主多从的设置主要用来读写分离，主库负责所有的写入和一部分读，其他的读请求由从库承担。 其中A'和A还互为主备库，当主库A发生故障时，A'会成为新的主库，此时从库B和C需要改到同步A'。 一般这种都会有专门的系统完成，我们可以看一下这种专门的系统大体有哪几种方式完成主备切换。 主备切换的方式有几种？ 基于位点的主备切换 基于GTID的主备切换 如何设置节点B成为A'的主库？ mysql主要有很多错误类型，如下两种： 1062：插入数据时唯一键冲突 1032：删除数据时找不到行 我们可以在mysql配置文件中添加以下内容： slave_skip_errors=1062,1032 等主备同步关系建立完成以后并且稳定执行一段时间，我们再还原参数，避免后续的问题。 什么是GTID？ 基于GTID的主备切换 -- master_host：主库A'的IP -- master_port：主库A'的端口 -- master_user：用户名 -- master_password：密码 change
2.5K10编辑于 2022-04-07 - 来自专栏xuefly
Mysql主备问题记录
备上报错找不到log文件， 问题背景：在配置好的mysql主备环境上，正常运行状态下，两台服务器断电，上电后报错如下： mysql报错 错误日志： 2019-08-05 09:35:43 29817 /mysql/bin/mysqld: File '/var/hms/base_service/mysql/backup/mysql-bin.000006' not found (Errcode: 2 - ，发现index中文件已经记录到mysql-bin.000006，而真实不存在这个文件，因此mysql启动时报找不到binlog日志文件； 解决此问题第一步： 编辑mysql-bin.index，删除 mysql-bin.000006记录，重启mysql，服务即可启动 第二步，在备机上发现主备同步状态未有任何改变；仍然报错，究其原因，实际上就是备机上的relay-bin log与主机上的mysql-bin log不匹配导致，思路就是清理掉备机上的relay log 在备机上进入mysql命令行执行： stop slave; reset slave; CHANGE MASTER TO MASTER_HOST
1.6K40编辑于 2022-12-30 - 来自专栏凝神长老和他的朋友们
MySQL备份与主备配置
MySQL备份与主备配置 数据备份类型 全量备份：备份整个数据库 增量备份：备份自上一次备份以来（增量或完全）以来变化的数据 差异备份：备份自上一次完全备份以来变化的数据 全量备份 全量备份的方法有 2 MySQL 主备配置 在主库上创建用户 repl，并给他权限。 [1557468786687] 主备延迟 最后需要说明的是，主备之间存在一个延迟。 主库 A 执行完成一个事务，写入 binlog，我们把这个时间记为 T1。 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2。 备库 B 执行完成这个事务，我们把这个时刻记为 T3。 主备延迟即 T3 - T1 的差。 练习 2 尝试配置MySQL一主一备及双主结构。 上文已详述。
2K30发布于 2020-04-15 - 来自专栏香菇带你用好IT工具
MySQL 5.7 主备切换详解
一、MySQL主备架构概述MySQL的主备架构通常包括一个主库（Master）和一个或多个备库（Slave）。 [mysqld] server-id=1 log-bin=mysql-bin备库配置：在备库的my.cnf文件中设置唯一的server-id，并启用中继日志。 备库的SQL线程读取relay log，解析出日志中的命令并执行，从而确保主备库数据同步。三、主备切换步骤准备环境：确保主库和备库能够互相通信，并且安装了相同版本的MySQL数据库。 如果需要，可以配置新的备库，并将其指向新的主库进行同步。四、备份与恢复在主备切换过程中，备份和恢复也是非常重要的环节。MySQL提供了多种备份工具和方法，如mysqldump和xtrabackup。 5.7的主备切换技术是实现高可用性的重要手段之一。
1.4K00编辑于 2024-10-16 - 来自专栏Porschev[钟慰]的专栏
MySQL数据同步【双主热备】
C:\Program Files\MySQL\MySQL Server X.Y). # 设置InnoDB存储引擎存放数据字典信息和内部数据结构的内存大小 innodb_additional_mem_pool_size=4M # If set to 1 设置主机并启动从服务器线程 服务242上用MySQL命令行工具执行如下语句： mysql> stop slave; mysql> change master to master_host='192.168.206.243 Show Slave Status 部分释义 ① Slave_IO_Status:线程已经连接上主服务器，正等待二进制日志事件到达。如果主服务器正空闲，会持续较长的时间。 4.查看同步后的数据 ? ? ------------------------------------------------------------- 大功告成，同步成功，且没有发生冲突！
3.1K111发布于 2018-01-16 - 来自专栏Se7en的架构笔记
MySQL + Keepalived 双主热备搭建
为了解决这个问题，可以采用 MySQL 双主模式，其中一台主库提供服务，另一台作为热备。结合 keepalived 使用虚拟 IP 对外提供服务，一旦主库发生故障，备库可以在很短的时间内接管服务。 interface ens192 # VRRP 实例绑定的网口，用于发送 VRRP 包 virtual_router_id 200 # 路由 ID，范围是 0-255，主备都一样 # 指定认证所使用的密码 mysql ，主备都一样 } track_script { # 调用"vrrp_script # VRRP 实例绑定的网口，用于发送 VRRP 包 virtual_router_id 200 # 路由ID，范围是0-255，主备都一样 # 指定认证所使用的密码 mysql ，主备都一样 } notify_master /etc/keepalived/notify_master_mysql.sh
6.1K21发布于 2021-09-15 - 来自专栏微观技术
京东一面：MySQL 主备延迟有哪些坑？主备切换策略
大家好，我是Tom哥 作为一名开发同学，大家对 MySQL 一定不陌生，像常见的 事务特性、隔离级别 、索引等也都是老生常谈。 今天，我们就来聊个深度话题，关于 MySQL 的 高可用 一、什么是高可用？ MySQL 的高可用是如何实现的呢？ 但有个前提，主备库的数据要同步。 不过，数据同步是个异步操作，不可能做到实时，所以说主备延迟是一定存在的 二、什么是主备延迟？ 主库完成一个事务，写入binlog。 1、可靠优先 当主库A 发生故障不可用时，开始进入主备切换 首先，判断 B库 seconds_behind_master 是否小于设定的阈值（比如 4 秒），如果满足条件 将 A库 改为只读状态，将
2.3K20编辑于 2022-04-07 - 来自专栏阿dai_linux
Keepalived-mysql高可用架构（主主热备）
Keepalived-mysql高可用架构（主主热备） 开始搭建该架构前已安装好mysql且主主热备已搭建完成，搭建方法详见：https://my.oschina.net/u/3497124/blog virtual_router_id 51 #主备相同 priority 100 #优先级，backup设置90 advert_int 1 nopreempt 2 #lb_algo rr #LVS算法，用不到，我们就关闭了 #lb_kind DR #LVS模式，如果不关闭，备用服务器不能通过VIP连接主MySQL virtual_router_id 51 #主备相同 priority 90 #优先级，backup设置90 advert_int 1 # nopreempt 2 #lb_algo rr #LVS算法，用不到，我们就关闭了 #lb_kind DR #LVS模式，如果不关闭，备用服务器不能通过VIP连接主MySQL
1K20发布于 2019-04-03 - 来自专栏PHPer 进击
MySQL 复制 - 性能与扩展性的基石 4：主备切换
一旦使用 MySQL 的复制功能，就很大可能会碰到主备切换的情况。也许是为了迭代升级服务器，或者是主库出现问题时，将一台备库转换成主库，或者只是希望重新分配容量。 不过出于什么原因，都需要将新主库的信息告诉其它备库。 对于主备切换，如果是计划内的操作，较为容易（至少比紧急情况下容易）。 2 计划外切换 当主库崩溃时，需要将一台备库提升为主库。这个过程就比较麻烦。如果只有一台备库，可以直接使用这台备库。但如果有超过一台的备库，就需要做一些额外的工作。 2.1 主备结构之备库提升 确定哪台备库的数据最新。 如果验证没问题，可以通过下面命令将 s3 切换为 s2 的备库： CHANGE MASTER TO MASTER_HOST="s2 host", MASTER_LOG_FILE="mysql-bin.000009
1K10发布于 2019-04-22 MySQL数据库主备同步原理
MySQL数据库的主备同步，也称为主从复制，是一种高可用的解决方案，旨在保证主备数据的一致性。这一机制在生产环境中尤为重要，因为它能确保在数据库服务出现故障时，快速切换到备库，避免应用不可用的情况。 本文将详细介绍MySQL数据库主备同步的原理及其实现过程。一、主备同步的基本概念主备同步是指将主库（Master）上的数据实时同步到备库（Slave）上，使得备库的数据与主库保持一致。 二、主备同步的实现原理MySQL主备同步的实现依赖于binlog（Binary Log，二进制日志）。Binlog记录了主库上的所有更改操作，备库通过读取和执行这些日志来保持数据一致性。 主备同步的完整过程设置主备关系：在备库上通过CHANGE MASTER TO命令设置主库的信息，包括IP地址、端口号、用户名、密码以及要从哪个位置的binlog开始复制。 三、主备同步的好处提升数据库的读并发性：大多数应用都是读比写要多，采用主备同步方案，可以扩展备库来提升读能力。备份：主备同步可以得到一份实时的完整的备份数据库。
2.3K00编辑于 2024-10-17- 来自专栏腾讯云混沌工程团队
【云顾问-混沌】云 MySQL 主备切换
MySQL 主备切换（Master-Slave Switching）是指在 MySQL 主从复制架构中，将从库（Slave）提升为主库（Master），原主库降为从库的过程。 腾讯云混沌演练平台可对云 MySQL 进行主备切换故障注入，通过混沌实验帮助构建高韧性的系统。 MySQL 主备切换故障原理 云数据库 MySQL 提供了一主一备的双节点实例和一主两备的三节点实例。 为了帮助用户在主实例故障的突发状况下能够及时进行主备切换，保证业务正常提供服务，混沌演练平台给用户提供了主备切换能力，支持用户通过手动进行主备切换过程，帮助用户验证主备切换的可靠性、数据的完整性和业务的整体稳定性等 为何需要进行 MySQL 主备切换障演练？ 主备切换（Master-Slave Switching）在 MySQL 主从复制架构中是一种常见的运维操作。 性能优化：通过定期进行主备切换，可以避免主库长时间运行导致的性能下降，确保整个数据库系统的高性能运行。 主备切换是 MySQL 数据库运维中的一种重要手段，可以提高系统的可用性、可靠性和性能。
1.2K10编辑于 2024-03-15 - 来自专栏John Wong's Blog
CentOS7 中 MySQL 5.7 主主互备配置
先从 MySQL 对数据库复制的能力看，MySQL 支持单向、异步的复制。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。 主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。 下面我们就介绍下 CentOS7 中如何搭建 MySQL 主主互备服务器。 1. MySQL 配置 既然是主主互备，就说明两个数据库都要对外进行服务，为了防止 id 重复，我们需要在配置文件中对两个数据库的自增长的 offset 设置为不同的值，具体如下： master-1 服务器中文件 replicate-ignore-db = performance_schema replicate-ignore-db = test 4.
1.9K11编辑于 2021-12-23 - 来自专栏云计算运维
MySQL主备的基本原理
那么，如果节点A同时是节点B的备库，相当于又把节点B新生成的binlog拿过来执行了一次，然后节点A和B间，会不断地循环执行这个更新语句，也就是循环复制 MySQL在binlog中记录了这个命令第一次执行时所在实例的 1、什么是主备延迟？ ，计算它与当前系统时间的差值，得到seconds_behind_master 如果主备库机器的系统时间设置不一致，不会导致主备延迟的值不准。 如果这时候发现主库的系统时间与自己不一致，备库在执行seconds_behind_master计算的时候会自动扣掉这个差值 网络正常情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差 主备延迟最直接的表现是，备库消费中转日志的速度，比主库生产binlog的速度要慢
1.1K10发布于 2021-08-11 - 来自专栏JavaEdge
主主、主从和主备区别
主主 两台都是主机，同时对外提供读写操作。客户端任意访问提供的一台。 主从 主备
3.5K20发布于 2021-10-18 - 来自专栏JavaEdge
主主、主从和主备区别
主主 两台都是主机，同时对外提供读写操作。客户端任意访问提供的一台。 主从 主备
2.3K21编辑于 2021-12-07 - 来自专栏洁癖是一只狗
Mysql主备一致性问题
我们今天简单了解一下主备库的基本原理。理解了背后设计原理, Mysql主备基本原理 下图就是基本的主备切换流程 ? ，造成主备不一致 可以用readonly状态，判断节点的角色 但是我们发现如果把备库设置成只读，那么主备如何同步更新呢，这个问题，是因为只读(readonly)设置对超级权限用户是无效的，而同步更新的线程 from t /*comment*/ where a>=4 and t_modified<='2018-11-10' limit 1; 这里要注意的是上面的注释，如果我们用mysql客户端来做这个实验的话 ，肯定会删除id=4这一行，不会有主备删除不通行的问题. 会占用很多空间，比如要删除10万行语句，我们既要记录都要写入binlog中，这样会导致io消耗，影响执行速度 最后如果使用mixed,mysql会判断sql如果可能导致主备不一致,如果有可能，就用row
1.3K30发布于 2020-12-16 - 来自专栏云计算运维
MySQL主备的基本原理2
忽略了备库的压力控制，导致备库上的查询耗费了大量的CPU资源，影响了同步速度，造成主备延迟 可以做以下处理： 一主多从。 2、可用性优先策略 可用性优先策略：如果强行把可靠性优先策略的步骤4、5调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库B，并且让备库B可以读写，那么系统几乎没有不可用时间。 (4,4)，之后开始进行主备切换 步骤3中，由于主备之间有5秒的延迟，所以备库B还没来得及应用插入c=4这个中转日志，就开始接收客户端插入c=5的命令 步骤4中，备库B插入了一行数据(4,5)，并且把这个 因此，大多数情况下，建议采用可靠性优先策略 五、MySQL的并行复制策略 image.png 主备的并行复制能力，要关注的就是上图中黑色的两个箭头。 一个代表客户端写入主库，另一个代表备库上sql_thread执行中转日志 在MySQL5.6版本之前，MySQL只支持单线程复制，由此在主库并发高、TPS高时就会出现严重的主备延迟问题 多线程复制机制都是把只有一个线程的
92120发布于 2021-08-11
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号