数据库容灾体系的演变
什么是容灾
备份的分类
| 备份方式 | 说明 |
|---|---|
| 逻辑备份 | 数据库对象级备份，备份内容是表、索引、存储过程等数据库对象，如MySQL mysqldump、Oracle exp/imp。 |
| 物理备份 | 数据库文件级备份，备份内容是操作系统上数据库文件，如MySQL XtraBackup、Oracle RMAN。 |
| 快照备份 | 基于快照技术获取指定数据集合的一个完全可用拷贝，随后可以选择仅在本机上维护快照，或者对快照进行数据跨机备份，如文件系统Veritas File System，卷管理器Linux LVM，存储子系统NetApp NAS。 |
规划
要结合业务，产生多维立体的解决方案。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-06-01
数据库 Resharding 的在线切换与回滚
Resharding 是分库分表架构绕不过去的难题。系统上线时用 uid % 2 把数据分到两个库，跑了两年发现容量不够，要扩成四个库——uid % 4。这个 % 号一变，大约 75% 的数据需要重新搬家。搬数据本身不难，难的是三件事同时做到：在线搬、搬完瞬间切、切坏了能回滚。 下面从最朴素的双写到 Vitess 的 VReplication，逐一拆解业界主流的 resharding 在线切换方案。核心问题只有三个：数据怎么不丢，流量怎么瞬间切，故障怎么秒级回。 问题的本质：hash mod 变化引发的数据海啸 hash 取模是最常见的分片路由策略。uid % N 的 N 一旦改变，绝大部分数据的归属分片都会变。 以 2 库扩 4 库为例：原先 uid % 2 = 0 的数据全在 A 库，扩容后 uid % 4 把这批数据拆成了 uid % 4 = 0（留 A 库）和 uid % 4 = 2（搬到新 C 库）。B 库的情况类似，一半数据要搬去新 D 库。 12345678910111213扩容前（uid % 2） 扩容后（uid % 4）┌─────────┐ ...
2017-11-15
MariaDB 调优相关
本文主要摘译自这里。 MySQL 曾经有独立的公司。但那间公司后来被 Sun 微系统公司获取了。 Sun 微系统公司又被 Oracle 获取了。原 MySQL 开发者担心 MySQL 成为闭源软件，因此成立了一家SkySQL 公司维护开源的 MySQL 分支–MariaDB。 MariaDB 支持的存储引擎包括： InnoDB/XtraDB 后者是前者的加强版，属于事务性存储引擎，也叫 ACID-compliant（ACID 遵从的）。XtraDB 是 Percona 开发的存储引擎，整体向下兼容。使用普通的 mysqldump 会耗尽 cpu（因为要把数据库转化成正经的 SQL 语句）。而 xtrabackup 在大库上的备份、还原、冗余都表现得更好（因为像 Oracle 一样是二进制备份吗？）。 TokuDB。另一个事务性存储引擎。以高压缩率著称（最高25倍压缩）。适合小空间存储大数据。 MyISAM。MySQL 上最古老的存储引擎。非事务性存储引擎，只支持表级锁，不支持 MVCC。 SphinxSE。非事务性存储引擎。这名字和古希腊猜谜语的怪兽，斯芬克斯一样。本以上是用...
2026-05-20
MyBatis 内部架构深度解析：从 Mapper 方法到 JDBC 执行链
MyBatis 的内部结构并不复杂，但很容易被看散：SqlSession、MapperProxy、MappedStatement、Executor、StatementHandler、TypeHandler、一级缓存、二级缓存、插件链分别出现在不同包里，单看任何一个类都像是局部技巧。把它们放回完整调用链之后，MyBatis 的设计会变得很清楚： MyBatis 的核心不是“把对象自动映射成表”，而是“把 Java 方法稳定地映射到一条可执行的 SQL 描述，再把执行过程拆成可替换的流水线组件”。 本文以 MyBatis 3.5.19 的官方文档与源码 XRef 为基准，重点讨论 MyBatis 运行时内部架构，不展开 MyBatis-Spring 的事务同步、Spring Boot 自动装配，也不讨论 MyBatis-Plus 等增强框架。 总体架构 MyBatis 可以分成两条主线：构建期主线和执行期主线。 构建期负责把 XML、注解、类型别名、类型处理器、插件、缓存配置等材料编译成一个 Configuration 对象。执行期从 SqlSessionFactory 打开 ...
2026-06-13
深翻页的本质：从 RDBMS 到 ES 和 Hive
分页通常是一个很安静的接口参数：page_no、page_size，或者 limit、offset。数据量小时，它几乎没有存在感；等列表长到几十万、几百万行之后，同一条 SQL 只是把 OFFSET 往后挪了一点，延迟却会突然变得难看。 问题不在“翻页”这个动作本身，而在系统被要求从一个有序结果集里跳过很长的前缀。RDBMS、Elasticsearch、Hive 的表现各不相同，底层代价却很接近：先把前面的候选算出来，再把它们丢掉。 这也是深翻页最容易被误解的地方。它不只是 SQL 写法问题，还牵涉访问路径、排序稳定性、产品交互，以及底层系统是否需要跨节点合并结果。一个可用的分页方案，往往先从产品语义开始，而不是从 LIMIT 990000, 1000 开始。 深翻页的成本来自“计算前缀再丢弃前缀”。优化要么把前缀变窄，要么把“第 N 页”改成“从某个锚点继续”，要么提前把结果集物化成可跳转目录。 一个大表实验 有一个很典型的大表实验：表里大约 1000 万行，按 status 过滤后命中约 100 万行。测试环境是本地硬盘，慢查询阈值按 100ms 估算。几条查询的结果很...
2021-03-11
MySQL 的 MGR
MySQL 高可用架构的历史 MySQL 自带的主从复制机制，本身并不能实现自动高可用。 早期使用开源组件来搭 MySQL 集群的方案，使用 MMHA。当代 MySQL 官方自己主推的方案是 MySQL cluster。这些老的方案，优先保证MySQL服务的持续可用，在异常切换情况下，可能出现主机上部分数据未能及时同步到从库，造成主从切换后数据丢失。但是包括金融支付在内的一些业务，对于数据库服务既要求持续可用、也要求数据强一致（可以在性能上做出一些让步）。 因此，当代的 MySQL 官方提供了组复制（MySQL Group Replication）的方案，构建了新一代的 MySQL 高可用强一致服务。 Master-Slave（MS）架构高可用概述 MS架构高可用基础 高可用MySQL是依赖复制（Replication）技术实现的，复制解决的基本问题就是，让一台数据库服务器的数据同步到其它服务器上。MySQL数据库的复制有如下三个步骤。 在主库上把数据更改记录到二进制日志（Binary Log）中（这些记录被称为二进制日志事件）。 备库将主库上的日志复制到自己的中继日志（...
2025-07-29
数据库写入的潜规则——合并树与 MPP 架构深度剖析
许多开发者在使用 ClickHouse、HBase、Elasticsearch 等现代数据系统时，都会遇到"不建议高频写入"的限制。这一限制常被归因于"列式存储"，但这是一个常见的误解。 高频写入受限的根本原因在于数据库的存储引擎架构。本文将深入剖析四大主流架构——LSM-Tree、ClickHouse MergeTree、MPP 和 B-Tree——分析它们各自的写入机制、性能权衡，以及它们"偏爱"批量写入的底层原因。 Part 1: 磁盘 I/O 基础——理解一切的前提 深入存储引擎之前，有必要先理解磁盘 I/O 的基本特性，因为所有存储引擎的设计都是围绕磁盘特性做出的权衡。 随机写 vs 顺序写 指标 HDD（机械硬盘） SSD（固态硬盘） 内存（DRAM） 随机写 IOPS ~100-200 10K-100K ~10M 顺序写吞吐 ~100-200 MB/s 500 MB/s - 3 GB/s ~10 GB/s 随机写延迟 ~10ms（寻道时间） ~100μs ~100ns 顺序写延迟...