数据库容灾体系的演变
什么是容灾
备份的分类
| 备份方式 | 说明 |
|---|---|
| 逻辑备份 | 数据库对象级备份，备份内容是表、索引、存储过程等数据库对象，如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
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。非事务性存储引擎。这名字和古希腊猜谜语的怪兽，斯芬克斯一样。本以上是用...
2021-03-28
MySQL 存储引擎 InnoDB 技术内幕
这本书的电子版的一个博客。 InnoDB.xmind 前言 MySQL 是处理海量数据（尤其 是OLTP 写入）时仍能获得最佳性能的最佳选择之一，它的 CPU 效率可能其他任何基于磁盘的关系型数据库所不能匹敌的-但它应该能够匹敌 Redis。 Think Different 而不是 Think Differently，这意味着要思考不同的东西，而不只是思考不同的方式。 不要相信网上的传言，去做测试，根据自己的实践做决定。很多伟大的作者写的伟大的书里面，关于性能的说法都来源于他们个人的随身电脑的直观测试。 change buffer 是 inert buffer 的升级版本。 MySQL 体系结构和存储引擎 定义数据库和实例 数据库：物理操作系统文件或其他形式文件类型的集合。 实例：操作系统后台进程（线程和一堆共享内存）。 存储引擎：基于表而不是基于库的，所以一个库可以有不同的表使用不同的存储引擎。 InnoDB 将数据存储在逻辑的表空间中，这个表空间就像黑盒一样。 存储引擎不一定需要事务。比如没有 ETL 的操作，单纯的查询操作不需要考虑并发控制问题，不需要产生一致性视图。...
2021-03-18
MySQL pitfalls 与配置札记（2018-2021 札记整合）
一、SQL 语义陷阱 引号的方言差异 标准的 SQL 中只允许用单引号表达字符串类型。有些 SQL 方言允许使用双引号包裹字符串，如 MySQL，有些则不允许，如 Oracle。 反引号是专门用来表达 identifier 的。 字符串与数字的隐式转换 pitfall Data truncation: Truncated incorrect 不要小看 MySQL，它出 warning 就一定有错误。 不要滥用 MySQL 字符串到decimal，和 decimal 到 string 的转换。这样有时候 MySQL 不只是 warning。 二、存储引擎对比 参考：https://www.zhihu.com/question/20596402 MyISAM 与 InnoDB 的区别 InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败； InnoDB 是聚集索引，MyISAM ...
2021-03-17
分库分表
业界方案问题 垂直拆分 优点：降低负载，提高可用性 缺点： 无法降低单表数据量 不能无限扩容 存在单点故障 join 等多表操作受限 存在跨库事务 水平拆分 优点： 降低单表数据量 理论上可无限扩容（NoSQL 通常采取这种方案） 不存在单点故障 缺点： join 等多表操作进一步受限 存在跨库事务 扩容成本高 如何分 hash 分表 常见的分表方案。 range 分表 建立时间 range，按 range 分表。 混合分表 先 hash，再 range。 怎么查 SQL 路由（route）和结果合并（merge） 多表 join 多维度查询 跨库事务 路由要定义 dsl，用语言解析表达式。 做广播表的查询的结果就是一张逻辑表查询转成多张表查询。 如果要做无分表键的查询，不如做影子表做侧维度。但影子表依赖于数据迁移服务。数据迁移服务的存在在日常的数据库运维中非常重要，它可以支持任意的 etl 的形式来同步异构数据。但这会带来成本上的坑。
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 顺序写延迟...
2018-06-06
log 的历史
Log：一种被低估的计算机科学基础抽象 在计算机科学中，log（日志）远不止是"打印调试信息"那么简单。从数据库的 WAL 到分布式系统的共识协议，从版本控制系统到区块链，log 作为一种 append-only 的有序记录序列，是贯穿整个计算机科学发展史的核心抽象之一。 LinkedIn 的前首席工程师 Jay Kreps 在其著名文章 “The Log: What every software engineer should know about real-time data’s unifying abstraction” 中指出：log 是一种比消息队列、数据库、文件系统更基础的抽象——后者都可以建立在 log 之上。 本文尝试梳理 log 这一抽象在不同技术领域中的演化脉络。 数据库中的 Log：WAL 与 Binlog WAL（Write-Ahead Logging） WAL 是数据库实现 ACID 特性的基石。其核心思想是：在修改数据页之前，先将修改操作写入日志。 WAL 的工作流程： 事务开始时，将修改操作（redo log entry）追加写...