## 背景
作为云计算的服务提供者,我们在向用户提供优秀的服务能力时会遇到一个合规的问题。在数据库领域,数据是极其敏感和珍贵的,保护好数据,就如保护好企业的生命线。因此,需要采取一些预防措施来帮助保护数据库的安全,如设计一个安全系统、加密机密资产以及在数据库服务器的周围构建防火墙。但是,如果遇到物理介质被盗的情况,恶意破坏方只需还原或附加数据库即可浏览数据,或者遭遇拖库情况。一种解决方案是加密数据库中的敏感数据,并通过证书保护用于加密数据的密钥。这可以防止任何没有密钥的人使用这些数据,但这种保护必须事先计划。在SQL Server中,透明数据加密 (TDE) 可以加密 SQL Server数据文件,能够有效保护好我们的数据资产。
## 实现原理
数据库文件的加密在页级别执行。已加密数据库中的页在写入磁盘之前会进行加密,在读入内存时会进行解密,TDE 不会增加已加密数据库的大小。TDE 可对数据和日志文件执行实时 I/O 加密和解密。这种加密使用数据库加密密钥,该密钥存储在数据库引导记录中以供恢复时使用。数据库加密密钥是使用存储在服务器的 master 数据库中的证书保护的对称密钥,或者是由 EKM 模块保护的非对称密钥。TDE 保护“处于休眠状态”的数据,即数据和日志文件。体系如下:
![](https://box.kancloud.cn/2016-06-02_574fe05b3816a.jpg)
## 实现方法
场景说明:
如果只是简单的配置一个加密数据库,如下步骤即可:创建主密钥,创建证书,创建DEK,应用加密,我们选取了一个比较复杂的场景,与数据库镜像的共存。同时镜像的创建是在非WINDOWS认证的安全策略,是通过证书的安全认证,这里涉及到master key等信息的特殊处理,证书的多样性。
下面列举实现的方法:首先,需要配置好用户数据库的镜像:
* 在principal: 创建master key
先判断是否存在master key, 如果存在可以先DROP再创建,因为涉及到master key密码需要利用,老的master key不一定记得住密码:
~~~
USE master
GO
CREATE MASTER KEY
ENCRYPTION BY PASSWORD='mypassword'
查询验证:
SELECT
*
FROM sys.symmetric_keys
WHERE name='##MS_DatabaseMasterKey##'
~~~
* 在Principal:创建镜像使用的证书
~~~
USE master
GO
CREATE CERTIFICATE cer_db_mirror_principal
WITH SUBJECT='certification for mirror',
START_DATE='01/01/1999',
EXPIRY_DATE='12/31/2099';
查询验证:
SELECT
*
FROM sys.certificates
WHERE name='cer_db_mirror_principal'
~~~
* 在principal: 创建镜像使用的端点
~~~
CREATE ENDPOINT endpoint_mirroring
STATE=STARTED
AS TCP (
LISTENER_PORT=5022, LISTENER_IP=ALL )
FOR data_mirroring(
AUTHENTICATION=CERTIFICATE cer_db_mirror_principal,
ENCRYPTION= REQUIRED ALGORITHM RC4, ROLE=ALL
)
查询验证:
SELECT
*
FROM sys.tcp_endpoints
WHERE name='endpoint_mirroring'
~~~
* 在principal: 备份master key
~~~
OPEN MASTER KEY
DECRYPTION BY PASSWORD = 'mypassword';
BACKUP MASTER KEY
TO FILE = 'D:\backup\master_key.mky'
ENCRYPTION BY PASSWORD = 'context'
~~~
* 在principal: 备份证书
~~~
BACKUP CERTIFICATE cer_db_mirror_principal
TO FILE='D:\backup\cer_db_mirror_principal.cer'
~~~
* 在mirror: 还原master key
~~~
RESTORE MASTER KEY
FROM FILE = 'D:\Backup\master_key.mky'
DECRYPTION BY PASSWORD = 'context'
ENCRYPTION BY PASSWORD = 'context';
查询验证:
SELECT
*
FROM sys.symmetric_keys
WHERE name='##MS_DatabaseMasterKey##'
~~~
* 在mirror: 创建证书
~~~
USE master
GO
OPEN MASTER KEY DECRYPTION BY PASSWORD = 'context'
CREATE CERTIFICATE cer_db_mirror_mirror
WITH SUBJECT='CERTIFICATION FOR MIRROR',
START_DATE='01/01/1999', EXPIRY_DATE='12/31/2099'
查询验证:
SELECT
*
FROM sys.certificates
WHERE name='cer_db_mirror_mirror'
~~~
* 在mirror: 创建端点
~~~
CREATE ENDPOINT endpoint_mirroring
STATE=STARTED
AS TCP (
LISTENER_PORT=5022, LISTENER_IP=ALL )
FOR DATA_MIRRORING(
AUTHENTICATION=CERTIFICATE cer_db_mirror_mirror,
ENCRYPTION= REQUIRED ALGORITHM RC4, ROLE=ALL
)
查询验证:
SELECT *
FROM sys.tcp_endpoints
WHERE name='endpoint_mirroring'
~~~
* 在mirror: 备份镜像证书
`BACKUP CERTIFICATE cer_db_mirror_mirror TO FILE='D:\Backup\cer_db_mirror_mirror.cer'`
* 在principal: 创建端点的连接认证用户
~~~
USE master
GO
CREATE LOGIN mirror_for_login
WITH PASSWORD=N'22266320-AA49-4F52-A38E-98D5DE313B85'
GO
CREATE USER mirror_for_user
FOR LOGIN mirror_for_login
~~~
* 在principal: 创建镜像的证书,以打通相互成功握手通道
~~~
CREATE CERTIFICATE cer_db_mirror_mirror
AUTHORIZATION mirror_for_user
FROM FILE='D:\Backup\cer_db_mirror_mirror.cer';
~~~
* 在principal: 为端点授权
~~~
GRANT CONNECT ON ENDPOINT::endpoint_mirroring TO mirror_for_login;
~~~
* 在mirror: 创建端点的连接认证用户
~~~
USE master
GO
CREATE LOGIN principal_for_login
WITH PASSWORD=N'dd266320-AA4d-4R52-G38E-9DF5DE313B85'
GO
CREATE USER principal_for_user
FOR LOGIN principal_for_login
~~~
* 在mirror: 创建镜像的证书,以打通相互成功握手通道
~~~
CREATE CERTIFICATE cer_db_mirror_principal
AUTHORIZATION principal_for_user
FROM FILE='D:\Backup\cer_db_mirror_principal.cer'
~~~
* 在mirror: 为端点授权
~~~
GRANT CONNECT ON ENDPOINT::endpoint_mirroring TO principal_for_login
~~~
* 在principal: 创建一个测试书库
~~~
CREATE DATABASE tde_mirror
~~~
* 在principal: 设置数据库的恢复模式为FULL,并备份数据库和日志
~~~
ALTER DATABASE tde_mirror
SET RECOVERY FULL
BACKUP DATABASE tde_mirror
TO DISK='D:\Backup\tde_mirror.bak'
WITH STATS=5,COMPRESSION
BACKUP LOG tde_mirror
TO DISK='D:\Backup\tde_mirror.trn'
WITH STATS=5,COMPRESSION
~~~
* 在mirror: 还原数据库
~~~
RESTORE DATABASE tde_mirror
FROM DISK='D:\Backup\tde_mirror.bak'
WITH STATS=5,NORECOVERY
RESTORE LOG tde_mirror
FROM DISK='D:\Backup\tde_mirror.trn'
WITH STATS=5,NORECOVERY
~~~
* 在mirror: 设置镜像
~~~
OPEN MASTER KEY DECRYPTION BY PASSWORD = 'context'
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY
ALTER DATABASE tde_mirror
SET PARTNER = 'TCP://10.0.0.1:5022' --ip address or host name
~~~
* 在principal: 应用镜像
~~~
ALTER DATABASE tde_mirror
SET PARTNER = 'TCP://10.0.0.2:5022' --ip address or host name
~~~
* 在principal: 创建TDE需要的证书
~~~
CREATE CERTIFICATE cer_tde
WITH SUBJECT='cert for tde',
START_DATE='01/01/1999',
EXPIRY_DATE='12/31/2099';
注意,创建完证书,数据库的同步状态可能会是SUSPEND,主备完成加密设置后才会恢复正常。
~~~
* 在principal: 在主库用户数据库创建DEK
~~~
USE tde_mirror
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128 ENCRYPTION
BY SERVER CERTIFICATE cer_tde
~~~
* 在principal: 设置数据库加密
~~~
USE master
GO
ALTER DATABASE tde_mirror
SET ENCRYPTION ON
查询验证:这个状态应该是3
SELECT
d.name,DEK.encryption_state
FROM sys.dm_database_encryption_keys dek
INNER JOIN sys.databases d
ON dek.database_id=d.database_id
~~~
* 在principal: 备份TDE证书
~~~
BACKUP CERTIFICATE cer_tde
TO FILE = 'D:\Backup\cer_tde.cer'
WITH PRIVATE KEY ( FILE = 'D:\Backup\cer_tde.pvk',
ENCRYPTION BY PASSWORD = 'tde_password');
~~~
* 在mirror: 创建证书
~~~
OPEN MASTER KEY DECRYPTION BY PASSWORD = 'context'
CREATE CERTIFICATE cer_tde
FROM FILE = 'D:\Backup\cer_tde.cer'
WITH PRIVATE KEY (FILE = 'D:\Backup\cer_tde.pvk',
DECRYPTION BY PASSWORD = 'tde_password')
验证: 这个状态应该是1,做FAILOVER后才变成3
SELECT
d.name,DEK.encryption_state
FROM sys.dm_database_encryption_keys dek
INNER JOIN sys.databases d
ON dek.database_id=d.database_id
~~~
## 总结
当TDE和镜像共存时,很多步骤还是不一样,配置也多了许多步骤,可以看出有几个点特别注意:第一是master key的处理方式;第二是镜像的证书和TDE证书的区分;第三是镜像数据库TDE的状态变化。
## 还原数据库
启用了 TDE 的数据库的备份文件也使用数据库加密密钥进行加密。因此,当您还原这些备份时,用于保护数据库加密密钥的证书必须可用。也就是说,除了备份数据库之外,您还要确保自己保留了服务器证书的备份以防数据丢失。如果证书不再可用,将会导致数据丢失。还原数据库需要解密过程,restore database, resotore filelistonly等等,都需要先还原证书,因此备份证书和密钥是必须的。
示例:
- 首先备份TDE证书
~~~
BACKUP CERTIFICATE cer_tde
TO FILE = 'D:\Backup\cer_tde.cer'
WITH PRIVATE KEY ( FILE = 'D:\Backup\cer_tde.pvk',
ENCRYPTION BY PASSWORD = 'tde_password');
~~~
* 备份数据库
~~~
BACKUP DATABASE tde_mirror
TO DISK='d:\backup\tde_mirror_201605.bak'
WITH STATS=5,COMPRESSION
~~~
* 在需要还原的数据库上创建TDE证书
~~~
CREATE CERTIFICATE cer_tde
FROM FILE = 'D:\Backup\cer_tde.cer'
WITH PRIVATE KEY (FILE = 'D:\Backup\cer_tde.pvk',
DECRYPTION BY PASSWORD = 'tde_password')
~~~
* 还原数据库
~~~
RESTORE FILELISTONLY
FROM DISK='D:\backup\tde_mirror_201605.bak'
RESTORE DATABASE tde_mirror
FROM DISK='D:\backup\tde_mirror_201605.bak'
~~~
## 透明数据库加密共存性
* 事务日志
允许数据库使用 TDE 具有将虚拟事务日志的剩余部分“清零”以强制加密下一个虚拟事务日志的效果。这可以保证在数据库设置为加密后事务日志中不会留有明文。所有在数据库加密密钥更改前写入事务日志的数据都将使用之前的数据库加密密钥加密。在数据库加密密钥修改过两次后,必须执行日志备份才能再次对数据库加密密钥进行修改
* tempdb系统数据库
如果 tempdb 实例中的任何用户数据库是使用 TDE 加密的,则会加密tempdb数据库。如果取消所有数据库加密状态,tempdb的加密数据库状态不会改变。
* 复制
复制不会以加密形式从启用了 TDE 的数据库中自动复制数据。如果您想保护分发和订阅服务器数据库,则必须单独启用 TDE。快照复制以及用于事务和合并复制的初始数据分发,都能够在未加密的中间文件(例如 bcp 文件)中存储数据。 在事务或合并复制期间,可以启用加密来保护通信信道。
* 与FileStream数据
即使启用了 TDE,也不会加密 FILESTREAM 数据。
* 内存中的OLTP
可在拥有内存中 OLTP 对象的数据库上启用 TDE。如果启用 TDE,则内存中 OLTP 日志记录会被加密。如果启用了 TDE,则不对 MEMORY_OPTIMIZED_DATA 文件组中的数据进行加密。
- 数据库内核月报目录
- 数据库内核月报 - 2016/09
- MySQL · 社区贡献 · AliSQL那些事儿
- PetaData · 架构体系 · PetaData第二代低成本存储体系
- MySQL · 社区动态 · MariaDB 10.2 前瞻
- MySQL · 特性分析 · 执行计划缓存设计与实现
- PgSQL · 最佳实践 · pg_rman源码浅析与使用
- MySQL · 捉虫状态 · bug分析两例
- PgSQL · 源码分析 · PG优化器浅析
- MongoDB · 特性分析· Sharding原理与应用
- PgSQL · 源码分析 · PG中的无锁算法和原子操作应用一则
- SQLServer · 最佳实践 · TEMPDB的设计
- 数据库内核月报 - 2016/08
- MySQL · 特性分析 ·MySQL 5.7新特性系列四
- PgSQL · PostgreSQL 逻辑流复制技术的秘密
- MySQL · 特性分析 · MyRocks简介
- GPDB · 特性分析· Greenplum 备份架构
- SQLServer · 最佳实践 · RDS for SQLServer 2012权限限制提升与改善
- TokuDB · 引擎特性 · REPLACE 语句优化
- MySQL · 专家投稿 · InnoDB物理行中null值的存储的推断与验证
- PgSQL · 实战经验 · 旋转门压缩算法在PostgreSQL中的实现
- MySQL · 源码分析 · Query Cache并发处理
- PgSQL · 源码分析· pg_dump分析
- 数据库内核月报 - 2016/07
- MySQL · 特性分析 ·MySQL 5.7新特性系列三
- MySQL · 特性分析 · 5.7 代价模型浅析
- PgSQL · 实战经验 · 分组TOP性能提升44倍
- MySQL · 源码分析 · 网络通信模块浅析
- MongoDB · 特性分析 · 索引原理
- SQLServer · 特性分析 · XML与JSON应用比较
- MySQL · 最佳实战 · 审计日志实用案例分析
- MySQL · 性能优化 · 条件下推到物化表
- MySQL · 源码分析 · Query Cache内部剖析
- MySQL · 捉虫动态 · 备库1206错误问题说明
- 数据库内核月报 - 2016/06
- MySQL · 特性分析 · innodb 锁分裂继承与迁移
- MySQL · 特性分析 ·MySQL 5.7新特性系列二
- PgSQL · 实战经验 · 如何预测Freeze IO风暴
- GPDB · 特性分析· Filespace和Tablespace
- MariaDB · 新特性 · 窗口函数
- MySQL · TokuDB · checkpoint过程
- MySQL · 特性分析 · 内部临时表
- MySQL · 最佳实践 · 空间优化
- SQLServer · 最佳实践 · 数据库实现大容量插入的几种方式
- 数据库内核月报 - 2016/05
- MySQL · 引擎特性 · 基于InnoDB的物理复制实现
- MySQL · 特性分析 · MySQL 5.7新特性系列一
- PostgreSQL · 特性分析 · 逻辑结构和权限体系
- MySQL · 特性分析 · innodb buffer pool相关特性
- PG&GP · 特性分析 · 外部数据导入接口实现分析
- SQLServer · 最佳实践 · 透明数据加密在SQLServer的应用
- MySQL · TokuDB · 日志子系统和崩溃恢复过程
- MongoDB · 特性分析 · Sharded cluster架构原理
- PostgreSQL · 特性分析 · 统计信息计算方法
- MySQL · 捉虫动态 · left-join多表导致crash
- 数据库内核月报 - 2016/04
- MySQL · 参数故事 · innodb_additional_mem_pool_size
- GPDB · 特性分析 · Segment事务一致性与异常处理
- GPDB · 特性分析 · Segment 修复指南
- MySQL · 捉虫动态 · 并行复制外键约束问题二
- PgSQL · 性能优化 · 如何潇洒的处理每天上百TB的数据增量
- Memcached · 最佳实践 · 热点 Key 问题解决方案
- MongoDB · 最佳实践 · 短连接Auth性能优化
- MySQL · 最佳实践 · RDS 只读实例延迟分析
- MySQL · TokuDB · TokuDB索引结构--Fractal Tree
- MySQL · TokuDB · Savepoint漫谈
- 数据库内核月报 - 2016/03
- MySQL · TokuDB · 事务子系统和 MVCC 实现
- MongoDB · 特性分析 · MMAPv1 存储引擎原理
- PgSQL · 源码分析 · 优化器逻辑推理
- SQLServer · BUG分析 · Agent 链接泄露分析
- Redis · 特性分析 · AOF Rewrite 分析
- MySQL · BUG分析 · Rename table 死锁分析
- MySQL · 物理备份 · Percona XtraBackup 备份原理
- GPDB · 特性分析· GreenPlum FTS 机制
- MySQL · 答疑解惑 · 备库Seconds_Behind_Master计算
- MySQL · 答疑解惑 · MySQL 锁问题最佳实践
- 数据库内核月报 - 2016/02
- MySQL · 引擎特性 · InnoDB 文件系统之文件物理结构
- MySQL · 引擎特性 · InnoDB 文件系统之IO系统和内存管理
- MySQL · 特性分析 · InnoDB transaction history
- PgSQL · 会议见闻 · PgConf.Russia 2016 大会总结
- PgSQL · 答疑解惑 · PostgreSQL 9.6 并行查询实现分析
- MySQL · TokuDB · TokuDB之黑科技工具
- PgSQL · 性能优化 · PostgreSQL TPC-C极限优化玩法
- MariaDB · 版本特性 · MariaDB 的 GTID 介绍
- MySQL · 特性分析 · 线程池
- MySQL · 答疑解惑 · mysqldump tips 两则
- 数据库内核月报 - 2016/01
- MySQL · 引擎特性 · InnoDB 事务锁系统简介
- GPDB · 特性分析· GreenPlum Primary/Mirror 同步机制
- MySQL · 专家投稿 · MySQL5.7 的 JSON 实现
- MySQL · 特性分析 · 优化器 MRR & BKA
- MySQL · 答疑解惑 · 物理备份死锁分析
- MySQL · TokuDB · Cachetable 的工作线程和线程池
- MySQL · 特性分析 · drop table的优化
- MySQL · 答疑解惑 · GTID不一致分析
- PgSQL · 特性分析 · Plan Hint
- MariaDB · 社区动态 · MariaDB on Power8 (下)
- 数据库内核月报 - 2015/12
- MySQL · 引擎特性 · InnoDB 事务子系统介绍
- PgSQL · 特性介绍 · 全文搜索介绍
- MongoDB · 捉虫动态 · Kill Hang问题排查记录
- MySQL · 参数优化 ·RDS MySQL参数调优最佳实践
- PgSQL · 特性分析 · 备库激活过程分析
- MySQL · TokuDB · 让Hot Backup更完美
- PgSQL · 答疑解惑 · 表膨胀
- MySQL · 特性分析 · Index Condition Pushdown (ICP)
- MariaDB · 社区动态 · MariaDB on Power8
- MySQL · 特性分析 · 企业版特性一览
- 数据库内核月报 - 2015/11
- MySQL · 社区见闻 · OOW 2015 总结 MySQL 篇
- MySQL · 特性分析 · Statement Digest
- PgSQL · 答疑解惑 · PostgreSQL 用户组权限管理
- MySQL · 特性分析 · MDL 实现分析
- PgSQL · 特性分析 · full page write 机制
- MySQL · 捉虫动态 · MySQL 外键异常分析
- MySQL · 答疑解惑 · MySQL 优化器 range 的代价计算
- MySQL · 捉虫动态 · ORDER/GROUP BY 导致 mysqld crash
- MySQL · TokuDB · TokuDB 中的行锁
- MySQL · 捉虫动态 · order by limit 造成优化器选择索引错误
- 数据库内核月报 - 2015/10
- MySQL · 引擎特性 · InnoDB 全文索引简介
- MySQL · 特性分析 · 跟踪Metadata lock
- MySQL · 答疑解惑 · 索引过滤性太差引起CPU飙高分析
- PgSQL · 特性分析 · PG主备流复制机制
- MySQL · 捉虫动态 · start slave crash 诊断分析
- MySQL · 捉虫动态 · 删除索引导致表无法打开
- PgSQL · 特性分析 · PostgreSQL Aurora方案与DEMO
- TokuDB · 捉虫动态 · CREATE DATABASE 导致crash问题
- PgSQL · 特性分析 · pg_receivexlog工具解析
- MySQL · 特性分析 · MySQL权限存储与管理
- 数据库内核月报 - 2015/09
- MySQL · 引擎特性 · InnoDB Adaptive hash index介绍
- PgSQL · 特性分析 · clog异步提交一致性、原子操作与fsync
- MySQL · 捉虫动态 · BUG 几例
- PgSQL · 答疑解惑 · 诡异的函数返回值
- MySQL · 捉虫动态 · 建表过程中crash造成重建表失败
- PgSQL · 特性分析 · 谈谈checkpoint的调度
- MySQL · 特性分析 · 5.6 并行复制恢复实现
- MySQL · 备库优化 · relay fetch 备库优化
- MySQL · 特性分析 · 5.6并行复制事件分发机制
- MySQL · TokuDB · 文件目录谈
- 数据库内核月报 - 2015/08
- MySQL · 社区动态 · InnoDB Page Compression
- PgSQL · 答疑解惑 · RDS中的PostgreSQL备库延迟原因分析
- MySQL · 社区动态 · MySQL5.6.26 Release Note解读
- PgSQL · 捉虫动态 · 执行大SQL语句提示无效的内存申请大小
- MySQL · 社区动态 · MariaDB InnoDB表空间碎片整理
- PgSQL · 答疑解惑 · 归档进程cp命令的core文件追查
- MySQL · 答疑解惑 · open file limits
- MySQL · TokuDB · 疯狂的 filenum++
- MySQL · 功能分析 · 5.6 并行复制实现分析
- MySQL · 功能分析 · MySQL表定义缓存
- 数据库内核月报 - 2015/07
- MySQL · 引擎特性 · Innodb change buffer介绍
- MySQL · TokuDB · TokuDB Checkpoint机制
- PgSQL · 特性分析 · 时间线解析
- PgSQL · 功能分析 · PostGIS 在 O2O应用中的优势
- MySQL · 引擎特性 · InnoDB index lock前世今生
- MySQL · 社区动态 · MySQL内存分配支持NUMA
- MySQL · 答疑解惑 · 外键删除bug分析
- MySQL · 引擎特性 · MySQL logical read-ahead
- MySQL · 功能介绍 · binlog拉取速度的控制
- MySQL · 答疑解惑 · 浮点型的显示问题
- 数据库内核月报 - 2015/06
- MySQL · 引擎特性 · InnoDB 崩溃恢复过程
- MySQL · 捉虫动态 · 唯一键约束失效
- MySQL · 捉虫动态 · ALTER IGNORE TABLE导致主备不一致
- MySQL · 答疑解惑 · MySQL Sort 分页
- MySQL · 答疑解惑 · binlog event 中的 error code
- PgSQL · 功能分析 · Listen/Notify 功能
- MySQL · 捉虫动态 · 任性的 normal shutdown
- PgSQL · 追根究底 · WAL日志空间的意外增长
- MySQL · 社区动态 · MariaDB Role 体系
- MySQL · TokuDB · TokuDB数据文件大小计算
- 数据库内核月报 - 2015/05
- MySQL · 引擎特性 · InnoDB redo log漫游
- MySQL · 专家投稿 · MySQL数据库SYS CPU高的可能性分析
- MySQL · 捉虫动态 · 5.6 与 5.5 InnoDB 不兼容导致 crash
- MySQL · 答疑解惑 · InnoDB 预读 VS Oracle 多块读
- PgSQL · 社区动态 · 9.5 新功能BRIN索引
- MySQL · 捉虫动态 · MySQL DDL BUG
- MySQL · 答疑解惑 · set names 都做了什么
- MySQL · 捉虫动态 · 临时表操作导致主备不一致
- TokuDB · 引擎特性 · zstd压缩算法
- MySQL · 答疑解惑 · binlog 位点刷新策略
- 数据库内核月报 - 2015/04
- MySQL · 引擎特性 · InnoDB undo log 漫游
- TokuDB · 产品新闻 · RDS TokuDB小手册
- PgSQL · 社区动态 · 说一说PgSQL 9.4.1中的那些安全补丁
- MySQL · 捉虫动态 · 连接断开导致XA事务丢失
- MySQL · 捉虫动态 · GTID下slave_net_timeout值太小问题
- MySQL · 捉虫动态 · Relay log 中 GTID group 完整性检测
- MySQL · 答疑释惑 · UPDATE交换列单表和多表的区别
- MySQL · 捉虫动态 · 删被引用索引导致crash
- MySQL · 答疑释惑 · GTID下auto_position=0时数据不一致
- 数据库内核月报 - 2015/03
- MySQL · 答疑释惑· 并发Replace into导致的死锁分析
- MySQL · 性能优化· 5.7.6 InnoDB page flush 优化
- MySQL · 捉虫动态· pid file丢失问题分析
- MySQL · 答疑释惑· using filesort VS using temporary
- MySQL · 优化限制· MySQL index_condition_pushdown
- MySQL · 捉虫动态·DROP DATABASE外键约束的GTID BUG
- MySQL · 答疑释惑· lower_case_table_names 使用问题
- PgSQL · 特性分析· Logical Decoding探索
- PgSQL · 特性分析· jsonb类型解析
- TokuDB ·引擎机制· TokuDB线程池
- 数据库内核月报 - 2015/02
- MySQL · 性能优化· InnoDB buffer pool flush策略漫谈
- MySQL · 社区动态· 5.6.23 InnoDB相关Bugfix
- PgSQL · 特性分析· Replication Slot
- PgSQL · 特性分析· pg_prewarm
- MySQL · 答疑释惑· InnoDB丢失自增值
- MySQL · 答疑释惑· 5.5 和 5.6 时间类型兼容问题
- MySQL · 捉虫动态· 变量修改导致binlog错误
- MariaDB · 特性分析· 表/表空间加密
- MariaDB · 特性分析· Per-query variables
- TokuDB · 特性分析· 日志详解
- 数据库内核月报 - 2015/01
- MySQL · 性能优化· Group Commit优化
- MySQL · 新增特性· DDL fast fail
- MySQL · 性能优化· 启用GTID场景的性能问题及优化
- MySQL · 捉虫动态· InnoDB自增列重复值问题
- MySQL · 优化改进· 复制性能改进过程
- MySQL · 谈古论今· key分区算法演变分析
- MySQL · 捉虫动态· mysql client crash一例
- MySQL · 捉虫动态· 设置 gtid_purged 破坏AUTO_POSITION复制协议
- MySQL · 捉虫动态· replicate filter 和 GTID 一起使用的问题
- TokuDB·特性分析· Optimize Table
- 数据库内核月报 - 2014/12
- MySQL· 性能优化·5.7 Innodb事务系统
- MySQL· 踩过的坑·5.6 GTID 和存储引擎那会事
- MySQL· 性能优化·thread pool 原理分析
- MySQL· 性能优化·并行复制外建约束问题
- MySQL· 答疑释惑·binlog event有序性
- MySQL· 答疑释惑·server_id为0的Rotate
- MySQL· 性能优化·Bulk Load for CREATE INDEX
- MySQL· 捉虫动态·Opened tables block read only
- MySQL· 优化改进· GTID启动优化
- TokuDB· Binary Log Group Commit with TokuDB
- 数据库内核月报 - 2014/11
- MySQL· 捉虫动态·OPTIMIZE 不存在的表
- MySQL· 捉虫动态·SIGHUP 导致 binlog 写错
- MySQL· 5.7改进·Recovery改进
- MySQL· 5.7特性·高可用支持
- MySQL· 5.7优化·Metadata Lock子系统的优化
- MySQL· 5.7特性·在线Truncate undo log 表空间
- MySQL· 性能优化·hash_scan 算法的实现解析
- TokuDB· 版本优化· 7.5.0
- TokuDB· 引擎特性· FAST UPDATES
- MariaDB· 性能优化·filesort with small LIMIT optimization
- 数据库内核月报 - 2014/10
- MySQL· 5.7重构·Optimizer Cost Model
- MySQL· 系统限制·text字段数
- MySQL· 捉虫动态·binlog重放失败
- MySQL· 捉虫动态·从库OOM
- MySQL· 捉虫动态·崩溃恢复失败
- MySQL· 功能改进·InnoDB Warmup特性
- MySQL· 文件结构·告别frm文件
- MariaDB· 新鲜特性·ANALYZE statement 语法
- TokuDB· 主备复制·Read Free Replication
- TokuDB· 引擎特性·压缩
- 数据库内核月报 - 2014/09
- MySQL· 捉虫动态·GTID 和 DELAYED
- MySQL· 限制改进·GTID和升级
- MySQL· 捉虫动态·GTID 和 binlog_checksum
- MySQL· 引擎差异·create_time in status
- MySQL· 参数故事·thread_concurrency
- MySQL· 捉虫动态·auto_increment
- MariaDB· 性能优化·Extended Keys
- MariaDB·主备复制·CREATE OR REPLACE
- TokuDB· 参数故事·数据安全和性能
- TokuDB· HA方案·TokuDB热备
- 数据库内核月报 - 2014/08
- MySQL· 参数故事·timed_mutexes
- MySQL· 参数故事·innodb_flush_log_at_trx_commit
- MySQL· 捉虫动态·Count(Distinct) ERROR
- MySQL· 捉虫动态·mysqldump BUFFER OVERFLOW
- MySQL· 捉虫动态·long semaphore waits
- MariaDB·分支特性·支持大于16K的InnoDB Page Size
- MariaDB·分支特性·FusionIO特性支持
- TokuDB· 性能优化·Bulk Fetch
- TokuDB· 数据结构·Fractal-Trees与LSM-Trees对比
- TokuDB·社区八卦·TokuDB团队