Big Date2.indd 11 16-11-22 下午3:38 12 而 MPP 数据库都不擅长做 OLTP 交易系统，所谓交易系统，就是高 频的交易型小规模数据插入、修改、删除，每次事务处理的数据量不大， 但每秒钟都会发生几十次甚至几百次以上交易型事务，这类系统的衡 量指标是 TPS，适用的系统是 OLTP 数据库或类似 GemFire 的内存数 据库。 5. Greenplum 16-11-22 下午3:38 Greenplum 精粹文集 25 这样做的好处是，所有链路 设备同时对外提供服务，并 互相备份，网络设备达到了 最大的高可用和吞吐，任意 网络硬件故障都不会影响集 群的正常使用。 ·Greenplum 软件本身不支持 RDMA（Remote Direct Memory Access）协议，所以如果基于 Infiniband 交换机对 Greenplum 集 群组网 该问题可能会导致实例启动失败。可在问题的实例（postgresql. conf）中设置参数 gp_persistent_repair_global_sequence=true， 便可修复相应问题，让相应实例正常启动。 3) 报错的实例日志中出现类似信息 Persistent 1663/17226/21248339, segment file #1, current new EOF is greater

Master 的自动故障切换，不过，已经有很多人适用工具或者 脚本的形式实现了 Master 和 Standby 的自动 FailOver 效果，编者也实现了自动 切换命令，当 Master 出现无法正常工作的故障时，自动激活 Standby 来接管 Master 的任务。下面的流程图，是编者实现的 Master 和 Standby 自动切换的逻辑流程图， 可以供读者参考，不过，编者不方便公开实现的代码。 分布策 略很不吻合，这时很可能导致工作负载的倾斜。例如，有一张交易流水表。该表的 DK为公司名称，那么数据分布的HASH算法将基于公司名称的值来计算，假如有一 个查询以某个特定的公司名称作为查询条件，该查询任务将仅在一个Instance 上执行。这里需要解释一下，这种交易流水表，特定公司名称可能会对应大量的记 录，这就导致，针对某些交易规模很大的公司进行查询时，繁重的计算任务由一个 Instanc Database 管理员指南 V6.2.1 版权所有：Esena(陈淼 +86 18616691889) 编写：陈淼 - 127 - 分区中存储的数据与其他普通的分区不应该有重叠，当然，在正常的插入数据时也是这 样检查的。经过编者测试，直接插入非法数据到默认分区是会报错的，只能通过设置 gp_enable_exchange_default_partition参数为on然后交换默认分区 WITHOUT

以下来自于在某大型银行的使用经验： 行存储和列存储： • 避免过多使用列存储的原因是防止小档数过多。 • 列存储能够提升查询性能，对于更新和全字段类操作性能反而会下降 • 对于少数频繁查询的宽表，例如交易表、帐户表、客户表等采用列存储，其它表采用行存储 数据压缩： • 在金融业，行压缩的数据压缩比在1:6左右，一般采用zlib5级压缩 • 数据压缩对于高并发查询分析系统可以大幅降低IO消耗，提升并行处理、混合负载的性能 con#sess_id#‖查看是否有进程处于 waiting状态  解决方法： – 如果是被其它回话锁了，需要等待其它回话结束或者Cancel； – 极端的情况下，某些回话虽然终止了，但事务没有正常终止，此时可以用UTILITY模式访问对应的Instance，将 其终止 ex： PGOPTIONS='-c gp_session_role=utility' psql-h segment_host 式 – PGOPTIONS='-c gp_session_role=utility' psql dbname –p xxxx – 可以通过这个命令登录实例，一般用于检测单个实例是否运行正常，还有就是用于在集群发生不一致时（只有在非常特殊的情况下才 有可能发生，如表不一致等），进行表维护 Admin常用命令  查看数据库、表占用空间 – select pg_size

高性能列式分析引擎。 Tiflash 是TiDB 数据库的扩展分析引擎，核心基于列存储引擎和矢量计算引擎， 与 TiDB 紧密集成，通 过Raft Learner副本技术同步数据，对TiDB 集群的 OLTP 交易几乎没有影响。提供和 TiDB 保持强一致 的数据读取，是真正的内核级 HTAP 分布式混合负载数据处理平台。 这套系统可以很好的解决: 行存储和列存储的取舍问题; OLTP 负载和 OLAP 群的节点，实现效益 / 成本的 最大化。 。 高可用: 数据的多个副本分布在云上不同的可用区，容忍单点故障，实现服务自 续性。 *。 HTAP: 支持面向关键业务的交易型工作负载和低延迟实时分析型工作负载，提供大规模的联机交易 处理 (OLTP) 与联机分析处理 (DOLAP) 的一站式解决方案。 。 多云支持: TiDB Cloud 当前支持用户选择在 AWS 或者 Google Cloud 分布式数据库实践 新一代财富管理平台是支撑光大银行理财公司运营的核心系统，提供理财业务的全流程管理。依托私有 云基础设施与平台 4.0 开发框架，光大银行定制了分布式批处理方案，设计目标是余额宝每小时理财交易 2000 万笔，零钱通单日 5000 万笔，同时还要满足未来 3-5 年业务发展和接入更多互联网代销渠道需求。 光大银行在同城两数据中心构建 TiDB 双活集群，采用 5副本 TiKV，设计 40TB

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 816 10.16.1 TiFlash 未能正常启动 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版 本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况 下，可以在同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。 • Region 的多副本丢失时，用户需要停机所有 TiKV， 使用 TiKV Control 逐一对 TiKV 进行恢复。从 TiDB v6.1.0 起，该过程被完全自动化且不需要停机，恢复过程 中不影响其他正常的在线业务。通过 PD Control 触发在线有损恢复数据，大幅简化了恢复步骤，缩短了 恢复所需时间，提供了更加友好的恢复摘要信息。 用户文档，#10483 • 历史统计信息采集持久化 支持通过

适用于需要实时处理的大规模数据和高并发场景。TiDB 在 4.0 版本中引入列存储引擎 TiFlash，结合 行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机 交易处理、实时数据分析，极大地节省企业的成本。 • 数据汇聚、二次加工处理的场景 TiDB 适用于将企业分散在各个系统的数据汇聚在同一个系统，并进行二次加工处理生成 T+0 或 T+1 的报 表。与 0/pd-microservices">支持拆分 PD 功能为微服务， �→ 提高可扩展性（实验特性） Placement Driver (PD) 包含了多个确保 TiDB 集群能正常运行的关键模块。当集群的工作负载增加时， �→ PD 中各模块的资源消耗也会随之增加，造成这些模块间功能的相互干扰， �→ 进而影响整个集群的服务质量。为了解决该问题，从 v8.0.0 起，TiDB 分统计信息过旧引发的性能问题，进而提升了数据库稳定性。 更多信息，请参考用户文档。 • 解除执行计划缓存的部分限制 #49161 @mjonss @qw4990 TiDB 支持执行计划缓存，能够有效降低交易类业务系统的处理时延，是提升性能的重要手段。在 v8.0.0 中，TiDB 解除了执行计划缓存的几个限制，含有以下内容的执行计划均能够被缓存： – 分区表 – 生成列，包含依赖生成列的对象（比如多值索引）

适用于需要实时处理的大规模数据和高并发场景。TiDB 在 4.0 版本中引入列存储引擎 TiFlash，结合 行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机 交易处理、实时数据分析，极大地节省企业的成本。 • 数据汇聚、二次加工处理的场景 TiDB 适用于将企业分散在各个系统的数据汇聚在同一个系统，并进行二次加工处理生成 T+0 或 T+1 的报 表。与 更多信息，请参考用户文档。 • 增强缓存非 Prepare 语句执行计划的能力（实验特性）#36598 @qw4990 TiDB v7.0.0 引入了非 Prepare 语句的执行计划缓存作为实验特性，以提升在线交易场景的并发处理能力。 在 v7.1.0 中，TiDB 继续增强非 Prepare 语句执行计划，支持缓存更多模式的 SQL。 为了提升内存利用率，TiDB v7.1.0 将非 Prepare 与 Prepare 资源将受到配额限制，防止某一资源组的过度消 耗对其他资源组的会话造成影响。 该特性也可以将多个来自不同系统的中小型应用整合到同一个 TiDB 集群中。即使某个应用的负载增加， 也不会影响其他应用的正常运行。而在系统负载较低的时候，繁忙的应用即使超出设定的配额，仍可 获得所需系统资源，实现资源的最大化利用。此外，合理利用资源管控特性可以减少集群数量，降低 运维难度及管理成本。 在 TiDB v7

Real-time HTAP 场景 场景 随着 5G、物联⽹、⼈⼯智能的⾼速发展，企业所⽣产的数据会越来越多，其规模可能达到数百 TB 甚⾄ PB 级别，传统的解决⽅案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 适⽤场景 分布式NewSQL数据库 TiDB Copyright © 2012-2021 UCloud 优刻得 14/120 ⼯具将数据同步到 OLAP 型数据库进⾏数据分析， ⾼、实时性差等多⽅⾯的问题。TiDB 在 4.0 版本中引⼊列存储引擎 TiFlash 结合⾏存储引擎 TiKV 构建真正 的 HTAP 数据库，在增加少量存储成本的情况下，可以在同⼀个系统中做联机交易处理、实时数据分析，极⼤地节省企业的成本。 数据汇聚、⼆次加⼯处理的场景 数据汇聚、⼆次加⼯处理的场景 当前绝⼤部分企业的业务数据都分散在不同的系统中，没有⼀个统⼀的汇总，随着业务的发展，企业的决策 Unknown or incorrect time zone: 'UTC' 错误 错误? 这是因为下游 MySQL 没有加载时区，可以通过 mysql_tzinfo_to_sql 命令加载时区，加载后就可以正常创建任务或同步任务。 mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p Q20: TiDB数据库报错 数据库报错 ERROR

适用于需要实时处理的大规模数据和高并发场景。TiDB 在 4.0 版本中引入列存储引擎 TiFlash，结合 行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机 交易处理、实时数据分析，极大地节省企业的成本。 • 数据汇聚、二次加工处理的场景 TiDB 适用于将企业分散在各个系统的数据汇聚在同一个系统，并进行二次加工处理生成 T+0 或 T+1 的报 表。与 MARKER，此时 TiDB 运行日志中的 SQL 文本会被标记。还可以通过 TiDB server 的 collect-log 子命令将日志中标记的敏感数 据删除，在数据安全的情况下展示日志；或移除所有标记，获取正常日志。该功能在 v8.1.0 成为正式功 能。 更多信息，请参考用户文档。 2.2.1.5 数据迁移 • IMPORT INTO ... FROM SELECT 语法成为正式功能 (GA) #49883 物理导入模式下导入数据时，从 PD 获取到的 Region 没有 Leader 的问题 #51124 #50501 @Leavrth * 修复日志备份在暂停、停止、再重建任务操作后，虽然任务状态显示正常，但 Checkpoint 不推 进的问题 #53047 @RidRisR * 修复不稳定测试用例 TestClearCache #51671 @zxc111 * 修复不稳定测试用例 TestG

适用于需要实时处理的大规模数据和高并发场景。TiDB 在 4.0 版本中引入列存储引擎 TiFlash，结合 行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机 交易处理、实时数据分析，极大地节省企业的成本。 • 数据汇聚、二次加工处理的场景 TiDB 适用于将企业分散在各个系统的数据汇聚在同一个系统，并进行二次加工处理生成 T+0 或 T+1 的报 表。与 起，BR 数 据恢复对 TiCDC 的限制被放宽：如果所恢复数据的 BackupTS（即备份时间）早于 Changefeed 的CheckpointTS （即记录当前同步进度的时间戳），BR 数据恢复可以正常进行。考虑到 BackupTS 的时间通常较早，此时 可以认为绝大部分场景下，当集群存在 TiCDC 同步任务时，BR 都可以进行数据恢复。#53131 @YuJuncen 2.2.2.2 MySQL @glorv – 修复 advance-ts-interval 配置未被用于限制 CDC 和 log-backup 模块中 check_leader 操作的 timeout， 导致在某些情况下 TiKV 正常重启时 resolved_ts lag 过大的问题 #17107 @MyonKeminta • PD – 修复 ALTER PLACEMENT POLICY 无法修改 placement policy