数据库容灾体系的演变
什么是容灾
备份的分类
| 备份方式 | 说明 |
|---|---|
| 逻辑备份 | 数据库对象级备份，备份内容是表、索引、存储过程等数据库对象，如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-13
深翻页的本质：从 RDBMS 到 ES 和 Hive
分页通常是一个很安静的接口参数：page_no、page_size，或者 limit、offset。数据量小时，它几乎没有存在感；等列表长到几十万、几百万行之后，同一条 SQL 只是把 OFFSET 往后挪了一点，延迟却会突然变得难看。 问题不在“翻页”这个动作本身，而在系统被要求从一个有序结果集里跳过很长的前缀。RDBMS、Elasticsearch、Hive 的表现各不相同，底层代价却很接近：先把前面的候选算出来，再把它们丢掉。 这也是深翻页最容易被误解的地方。它不只是 SQL 写法问题，还牵涉访问路径、排序稳定性、产品交互，以及底层系统是否需要跨节点合并结果。一个可用的分页方案，往往先从产品语义开始，而不是从 LIMIT 990000, 1000 开始。 深翻页的成本来自“计算前缀再丢弃前缀”。优化要么把前缀变窄，要么把“第 N 页”改成“从某个锚点继续”，要么提前把结果集物化成可跳转目录。 一个大表实验 有一个很典型的大表实验：表里大约 1000 万行，按 status 过滤后命中约 100 万行。测试环境是本地硬盘，慢查询阈值按 100ms 估算。几条查询的结果很...
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 顺序写延迟...
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 打开 ...
2021-03-01
HTAP 问题
问题定义 AP 的出现 在互联网浪潮出现之前，企业的数据量普遍不大，单机数据库就足以保存核心业务数据。那时候的存储不需要复杂架构，所有线上请求（OLTP，Online Transaction Processing）和后台分析（OLAP，Online Analytical Processing）都跑在同一个数据库实例上。后来业务越来越复杂，数据量越来越大，问题随之而来：单机数据库支持线上 TP 请求已经非常吃力，再跑较重的 AP 分析任务无以为继。AP 由此从 TP 系统分离，某种程度上 AP 是 TP 的一个分支。 这等于在存储层做读写分离的架构设计；另一种思路是在应用层做读写分离。 AP 的玩法 在这种背景下，以 Hadoop 为代表的大数据技术开始蓬勃发展，它用大量相对廉价的 x86 机器构建了一个数据分析平台，用并行能力破解大数据集的计算问题。 AP 系统的典型技术栈演进： 阶段 代表技术 特点 第一代 Hadoop MapReduce + Hive 批处理，延迟高（分钟到小时级） 第二代 Spark + Spark SQL 内存计算，延迟降到秒级 第...
2021-03-28
MySQL 存储引擎 InnoDB 技术内幕
这本书的电子版的一个博客。 InnoDB.xmind 前言 MySQL 是处理海量数据（尤其 是OLTP 写入）时仍能获得最佳性能的最佳选择之一，它的 CPU 效率可能其他任何基于磁盘的关系型数据库所不能匹敌的-但它应该能够匹敌 Redis。 Think Different 而不是 Think Differently，这意味着要思考不同的东西，而不只是思考不同的方式。 不要相信网上的传言，去做测试，根据自己的实践做决定。很多伟大的作者写的伟大的书里面，关于性能的说法都来源于他们个人的随身电脑的直观测试。 change buffer 是 inert buffer 的升级版本。 MySQL 体系结构和存储引擎 定义数据库和实例 数据库：物理操作系统文件或其他形式文件类型的集合。 实例：操作系统后台进程（线程和一堆共享内存）。 存储引擎：基于表而不是基于库的，所以一个库可以有不同的表使用不同的存储引擎。 InnoDB 将数据存储在逻辑的表空间中，这个表空间就像黑盒一样。 存储引擎不一定需要事务。比如没有 ETL 的操作，单纯的查询操作不需要考虑并发控制问题，不需要产生一致性视图。...
2021-03-17
分库分表
业界方案问题 垂直拆分 优点：降低负载，提高可用性 缺点： 无法降低单表数据量 不能无限扩容 存在单点故障 join 等多表操作受限 存在跨库事务 水平拆分 优点： 降低单表数据量 理论上可无限扩容（NoSQL 通常采取这种方案） 不存在单点故障 缺点： join 等多表操作进一步受限 存在跨库事务 扩容成本高 如何分 hash 分表 常见的分表方案。 range 分表 建立时间 range，按 range 分表。 混合分表 先 hash，再 range。 怎么查 SQL 路由（route）和结果合并（merge） 多表 join 多维度查询 跨库事务 路由要定义 dsl，用语言解析表达式。 做广播表的查询的结果就是一张逻辑表查询转成多张表查询。 如果要做无分表键的查询，不如做影子表做侧维度。但影子表依赖于数据迁移服务。数据迁移服务的存在在日常的数据库运维中非常重要，它可以支持任意的 etl 的形式来同步异构数据。但这会带来成本上的坑。