中国用户大会 PostgreSQL WAL日志解析与应用 王硕 山东瀚高基础软件股份有限公司 2016Postgres中国用户大会 Postgres Conference China 2016 中国用户大会 CONTENTS Part 01 Part 02 Part 03 WAL 日志简介 WAL 日志工作原理 利用 WAL 日志我们可以做什么？ 2016Postgres中国用户大会 Postgres Conference China 2016 中国用户大会 Part 01 WAL 日志简介 2016Postgres中国用户大会 Postgres Conference China 2016 中国用户大会  Write Ahead Log Files • WAL 日志一般存储在$PGDATA/pg_xlog内，他们一般以类似于 00000001 LogId LogSeg • WAL 日志文件XLOG 文件是一个逻辑概念，每一个XLOG文件， 大小为4G(16*256) ，由256个segment组成； • Segment由2048个Block组成，其大小为16M ； • Block为WAL日志的最小单位， 其大小8k，由PageHeaderData 、 XlogRecord、 XLogRecData组成。

● 事务实现原理和Write Ahead Logging（WAL） ● 分布式事务和两阶段提交的原理 ● Greenplum两阶段提交协议的实现 ● Greenplum两阶段提交协议的优化 Outline 7 事务的属性：ACID 属性 含义 数据库系统的实现 Atomic 原子性 事务中的操作要么全部正确执行，要么完全不 执行。 Write Ahead Logging，分布式事务：两阶段提交协议 Control、 两阶段加锁（Two Phase Locking, 2PL）、乐观并发控制 （OCC） Durability 持久性 一个事务在提交之后，该事务对数据库的改变 是持久的。 Write Ahead Logging + 存储管理 Jim Gray于1981年VLDB描述了事务的原子性、一致性和持久性，在此基础上，Haerder和Reuter在1983年中提出了事务的隔离性并提出术语 No-Force → Redo Log 事务提交时，数据页不需要刷回持久存储，为了保证持久性，先把Redo Log写 入日志文件。Redo log记录修改数据对象的新值(After Image, AFIM) ■ Steal → Undo Log 允许Buffer Pool未提交事务所修改的脏页刷回到持久存储，为了保证原子性， 先把Undo Log写入日志文件。Undo Log记录修改数据对象的旧值(Before

Re ad /w ri te S pl it ti ng Read/write splitting can be used to cope with business access with high stress. Sharding‐ Sphere provides flexible read/write splitting capabilities and can achieve read other, and mul‐ tiple components can be used together by overlaying. It includes data sharding, read/write splitting, data encryption and shadow database and so on. The user‐defined feature can be fully customized faced the bottleneck with increasing TPS. For the application with massive concurrence read but less write in the same time, we can divide the database into a primary database and a replica database. The

READWRITE_SPLITTING dataSourceGroups: (+): # 读写分离逻辑数据源名称，默认使用 Groovy 的行表达式 SPI 实现来 解析 write_data_source_name: # 写库数据源名称，默认使用 Groovy 的行表达式 SPI 实现来解析 read_data_source_names: # 读库数据源名称，多个从数据源用逗号分隔，默认使用 使用读写分离数据源 配置示例 rules: - !READWRITE_SPLITTING dataSourceGroups: readwrite_ds: writeDataSourceName: write_ds readDataSourceNames: - read_ds_0 - read_ds_1 transactionalReadQueryStrategy: PRIMARY loadBalancerName: dataSourceConfig = new ReadwriteSplittingDataSourceRuleConfiguration( "demo_read_query_ds", "demo_write_ds", Arrays.asList("demo_read_ds_ 0", "demo_read_ds_1"), "demo_weight_lb"); Properties algorithmProps

/home/gpadmin/pgbouncer_users.list auth_hba_file = /home/gpadmin/pgbouncer_hba.conf logfile = /data/pgbouncer.log pidfile = /tmp/.pgbouncer.pid admin_users = gpadmin stats_users = gpadmin ignore_startup_parameters 将需要全量恢复或者需要选择全量恢复。在 6 之前的版本，GP 的 Primary 和 Mirror 之间采用的是 filerep 的方式进行 block 级别的变化同步的机制，从 6 版本开始， 使用 WAL 复制，这将可以从根本上解决以往的 block 损毁被复制到 Mirror 上的问题， 也不再需要 persistent 系统表了(这个的确是一个让人很头疼的设计)。 在未启用 Mirror 不可用时，Standby 可以被激活以 接替 Master 的角色。Standby 与 Master 之间保持 WAL 同步，保证与 Master 之 间的实时一致性。 在 Master 失效时，WAL 同步的复制进程会自动停止，同时，Standby 可以被激 活。在 Standby 上，冗余的 WAL 日志会被用来将状态恢复到最后成功提交(commit) 时的状态。激活的 Standby 实际上会成为

data-dir 参数控制。 TiDB 集群的三个组件（ tidb-server 、 tikv-server 、 pd-server ）默认会将日志输出到标准错误中，并且三个 组件都支持设置 --log-file 启动参数 （或者是配置文件中的配置项）将日志输出到文件中。 通过配置文件可以调整日志的行为，具体信息请参见各个组件的配置文件说明。例如： tidb-server 日志配置项。 TiDB 接受许多的启动参数，执行这个命令可以得到一个简要的说明： 1. ./tidb-server --help 获取版本信息可以使用下面命令： 1. ./tidb-server -V 以下是启动参数的完整描述。 Log 级别 默认: “info” 可选值包括 debug, info, warn, error 或者 fatal TiDB 服务监听端口 默认: “4000” TiDB 服务将会使用这个端口接受 MySQL 0 默认会监听所有的网卡 address。如果有多块网卡，可以指定对外提供服务的网卡，譬如 192.168.100.113 Log 文件 默认: “” 如果没设置这个参数，log 会默认输出到 “stderr”，如果设置了， log 就会输出到对应的文件里面，在每 天凌晨，log 会自动轮转使用一个新的文件，并且将以前的文件改名备份 Prometheus Push Gateway 地址 默认: “”

READWRITE_SPLITTING dataSources: (+): # 读写分离逻辑数据源名称，默认使用 Groovy 的行表达式 SPI 实现来 解析 write_data_source_name: # 写库数据源名称，默认使用 Groovy 的行表达式 SPI 实现来解析 read_data_source_names: # 读库数据源名称，多个从数据源用逗号分隔，默认使用 使用读写分离数据源 配置示例 rules: - !READWRITE_SPLITTING dataSources: readwrite_ds: writeDataSourceName: write_ds readDataSourceNames: - read_ds_0 - read_ds_1 transactionalReadQueryStrategy: PRIMARY loadBalancerName: dataSourceConfig = new ReadwriteSplittingDataSourceRuleConfiguration( "demo_read_query_ds", "demo_write_ds", Arrays.asList("demo_read_ds_ 0", "demo_read_ds_1"), "demo_weight_lb"); Properties algorithmProps

参数解释 读写分离 rules: - !READWRITE_SPLITTING dataSources: (+): # 读写分离逻辑数据源名称 write_data_source_name: # 写库数据源名称 read_data_source_names: # 读库数据源名称，多个从数据源用逗号分隔 transactionalReadQueryStrategy 使用读写分离数据源 配置示例 rules: - !READWRITE_SPLITTING dataSources: readwrite_ds: writeDataSourceName: write_ds readDataSourceNames: - read_ds_0 - read_ds_1 transactionalReadQueryStrategy: PRIMARY loadBalancerName: dataSourceConfig = new ReadwriteSplittingDataSourceRuleConfiguration( "demo_read_query_ds", "demo_write_ds", Arrays.asList("demo_read_ds_ 0", "demo_read_ds_1"), "demo_weight_lb"); Properties algorithmProps

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 835 8.12.5 第 5 步：使用 redo log 确保数据一致性· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 835 8.12.6 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 2337 13.10.11TiDB Binlog Relay Log · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 景下安全使用 TiDB 日志，提升了使用日志脱敏能 力的安全性和灵活性。要使用此功能，可以将系统变量 tidb_redact_log 的值设置为 MARKER，此时 TiDB 运行日志中的 SQL 文本会被标记。还可以通过 TiDB server 的 collect-log 子命令将日志中标记的敏感数 据删除，在数据安全的情况下展示日志；或移除所有标记，获取正常日志。该功能在 v8.1.0 成为正式功

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 825 8.12.5 第 5 步：使用 redo log 确保数据一致性· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 825 8.12.6 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 2234 13.10.11TiDB Binlog Relay Log · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 子句时，优化器将根 据SQL 模式及 TiFlash 副本的代价估算自行决定是否将查询下推至 TiFlash。因此，在实验特性阶段引入的系 统变量 tidb_enable_tiflash_read_for_write_stmt 将被废弃。需要注意的是，TiFlash 对于 INSERT INTO �→ SELECT 语句的计算规则不满足 STRICT SQL Mode 要求，因此只有当前会话的SQL 模式为非严格模式