数据库容灾体系的演变
什么是容灾
备份的分类
| 备份方式 | 说明 |
|---|---|
| 逻辑备份 | 数据库对象级备份，备份内容是表、索引、存储过程等数据库对象，如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
2020-09-14
MySQL 的配置
123456789101112131415161718-- 查看自动提交SELECT @@autocommit-- 查看全局隔离级别和会话隔离级别SELECT @@global.tx_isolation, @@tx_isolation;-- 查看引擎的事务状态，这里可以看出死锁日志，但需要 PROCESS privilege(s)show engine innodb status# 查看表详情show table status like 'dept_emp'# 查看当前存储引擎默认的行格式SHOW VARIABLES LIKE '%innodb_default_row_format%'# 查看全部 binlog 文件show binary logs;# 查看最新的binlog，带有 positionshow master status; # 查看某个 binlog 的内容show binlog events in 'binlog.000156';
2021-03-10
秒杀通用解决方案
秒杀的实质 秒杀的实质，是围绕库存管理展开的并发读写 如果架构设计里面包含商品系统，包含库存，秒杀就要解决库存热点行高并发读写问题。 秒杀的底线是：不能超卖。qty库存 ≥ qty卖出 && qty库存 - qty卖出 ≈ 0。 秒杀能够容忍的一些思路：渐进趋于一致，允许漏卖。 秒杀架构的特性 高性能：秒杀架构要承载的访问流量比平时高出许多倍，涉及大量的并发读和并发写，因此支持高并发访问非常关键。 一致性：秒杀活动中有限数量的商品在同一时刻被很多倍的请求同时扣减库存，在大并发更新的过程中要保证数据准确，不能发生超卖的问题（超卖，本来应该卖完下架的商品，在前台展示依然有库存，依然不停的被卖出），即库存是多少，理应卖出多少（qty库存 ≥ qty卖出 && qty库存 - qty卖出 ≈ 0）。 高可用：秒杀架构虽经多次打磨优化，但现实中总难免出现一些考虑不到的情况，要保证系统的高可用，还要设计一个兜底预案，以便在最坏的情况发生时仍能从容应对。 秒杀技术难点 在有限的资源下，秒杀链路承载合理的最大流量。 大并发下扣减库存准确，“一致性...
2018-05-29
JPA 的 id 生成策略
JPA 有一个@GeneratedValue注解，有一个strategy attribute，如 @GeneratedValue(strategy = GenerationType.IDENTITY)。 常见的可选策略主要有IDENTITY和SEQUENCE。 GenerationType.IDENTITY 要求底层有一个 integer 或者 bigint 类型的自增列（ auto-incremented column)。自增列的赋值必须在插入操作之后发生，因为这个原因，Hibernate 无法进行各种优化（特别是 JDBC 的 batch 处理，一次 flush 操作会产生很多条insert 语句，分别执行）。如果事务回滚，自增列的值就会被丢弃。数据库在这个自增操作上有个高度优化的轻量级锁机制，性能非常棒。 MySQL 支持这种 id 生成策略， 使用 MySQL 应该尽量使用这个策略，即使它无法优化。 JPA 用它生成 id，会一条一条地插入新的 entity。 GenerationType.SEQUENCE 数据库有一个所谓的 sequence 对象，可以通过 selec...
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 顺序写延迟...
2021-12-10
MyBatis 关键代码分析
如何创建 SqlSession org.apache.ibatis.session.defaults.DefaultSqlSessionFactory 12345678910111213141516171819202122232425262728// 在应用程序中通过sqlSessionFactory获取一个SqlSession对象执行CRUD操作SqlSession sqlSession = sqlSessionFactory.openSession(true);// 在DefaultSqlSessionFactory中获取SqlSession对象@Overridepublic SqlSession openSession(boolean autoCommit) { return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, autoCommit);}// 通过MyBatis配置参数构建SqlSession对象private SqlSession open...
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。非事务性存储引擎。这名字和古希腊猜谜语的怪兽，斯芬克斯一样。本以上是用...