改进与实现 • 问题 – 生成模板的过程中，如果catalog被修改怎么保证一致性 ▪ 新增catalog锁 ▪ select gp_expand_lock_catalog() ▪ expand过程中申请写锁 ▪ 其他修改catalog操作时也会申请锁来实现与expand的互斥 改进与实现 • 数据重分布的优化 – 扩容后，新节点没有数据，查询Plan如何做？？？ ▪ 在Greenplum 配Gang ▪ 增加新节点后，对每个表做EXPAND后该值会随着改成新集群的大小 改进与实现 改进与实现 • EXPAND每个表 – 对表加最高级别锁（其他读写均被阻塞） – 移动数据到新节点 – 修改numsegments – 释放锁 改进与实现 • numsegments的收益 – 不需要将表改成随机分布，单表查询可以做优化 – 对于Join查询，如果分布状态相同的情况下，可以被优化

一直是使用资源队列来管理资源，资源队列最常见的使用 场景就是限制并发查询的数量。资源队列是基于查询语句来做并发控制的，而资源组是 基于事务来做并发控制。所以在资源队列中可能会出现多语句的事务之间的死锁现象， 一边在等资源队列的锁，另一边在等对象的锁，这种情况在资源组中不会出现，因为资 源组是以事务为单位进行排队的。因此，资源队列存在死锁风险，虽然概率很低。 资源队列如何工作 在安装GP时缺省使用资源队列来管理资 18616691889) 编写：陈淼 - 69 - 式排队。在查询优先级启用的情况下，系统会定期的重新分配计算资源。编者想说，排 队也是要消耗内存的，资源队列的排队相当于是在等待锁，而且查询的执行计划已经生 成并开始执行，只是未获取必要的锁，实际上内存已经分配，如果有大量消耗大量内存 的语句在排队，可能会出现内存不足的报错。 超级用户是不受资源队列限制的。超级用户的查询语句总是被立即执行，不管其所 TE和DELETE锁级 别的目标，在6以前的版本中，无论是Heap表还是AO(Column表也是AO表的一种，虽 然有人喜欢称为CO表)表，UPDATE和DELETE操作都是EXCLUSIVE锁，也就是说，在6 之前的版本，一张表上，同时只能有一个UPDATE或者DELETE的语句正在被执行，其 他的UPDATE或者DELETE语句需要等待前面的语句执行完成之后才能获得所需要的锁。 在

Ullman/Jennifer Widom《数据库系统实现》 查询编译器/ 优化器 事务管理器 DDL编译器 执行引擎 日志和恢复 并发控制 索引/文件/ 记录管理器 缓冲区管理器 缓冲区 锁表 存储管理器 存储 查询计划 对索引、文件和 记录的请求 页命令 事务命令 查询、更新 用户/ 应用 DDL命令 数据库管理员 数据、元数据、索引 日志页 读、写页 元数据、 PREPARED ● ROLLBACK PREPARED 30 问题 1：协调者向参与者发prepare之后，参与者完成prepare相应操作，在发送ready之前，会把日志 落盘。那参与者申请的锁会不会释放？ postgres=# begin ; BEGIN postgres=*# update t1 set c1 = 14 where c1 =15 ; UPDATE 1 postgres=*# wExclusive锁还在pg_lock里， 31 在PG里，执行完PREPARE语句之后，此时把数据库停掉（或者杀掉所有数据库进程）再启动起来，会发 现pg_locks里，prepared事务所申请的还在pg_lock表里。 问题2: 既然pg_locks是一个内存的数据结构，记录各个backend进程申请的锁，那数据库重启后，为什 么已经prepared事务申请的锁仍在pg_lock表呢？

processing - 联机事务处理 出色的OLTP特性 天生的优势 ● 行式存储 ● 索引 ● 直接分发 ● 完整的增删改 Greenplum 6 增强 ● 并发修改、删除 ● 系统性的优化事务和锁 26 Pivotal Confidential–Internal Use Only 行式存储 表‘SALES’ 表‘SALES’ ■ 更适合OLTP负载 ■ 高效更改和删除 ■ 适合需要全部或者多数列的查询 6：并发改删和分布式死锁检测 全局死 锁检测 gpconfig -c ‘gp_enable_global_deadlock_detector’ -v on 31 Pivotal Confidential–Internal Use Only Greenplum 6：锁和事务的优化 表‘SALES’ 表‘SALES’ ■ 大幅减少事务开始和结束时的锁冲突 ■ 消除隐式只读操作（单条SELECT）的锁冲突 ■ 避 避免显式只读事务（BEGIN-SELECT-END）的两阶段提交 （开发中） ■ fastpath锁（PostgreSQL合并） 32 Pivotal Confidential–Internal Use Only TPC-B基准测试：环境 基于谷歌云平台（Google Cloud Platform，简称GCP），为5个虚拟主机的集群，包含一 个master主机和四个segment主机，mas

当一个SQL 较长时间都都没有完成，可以怀疑是某些资源被LOCK了  查看是否被锁的方法： – Select*from pg_state_acitivty的waiting状态是否为true – Select*fromgp_toolkit.gp_locks_on_relation查看在哪个资源上被锁了 – 有些时候是lock在Segment上，使用gpssh -f allhosts allhosts -e ―ps –ef |grep con#sess_id#‖查看是否有进程处于 waiting状态  解决方法： – 如果是被其它回话锁了，需要等待其它回话结束或者Cancel； – 极端的情况下，某些回话虽然终止了，但事务没有正常终止，此时可以用UTILITY模式访问对应的Instance，将 其终止 ex： PGOPTIONS='-c gp_s gpstate检查是否有实例down机 – 检查pg_log是否有OOM錯誤  检查当前SQL任务 – 确定当前系統是否有SQL能执行成功（checkpoint、select用户表），还是整個系统挂起 – 确定是否有锁等待或资源队列排队导致SQL长时间不能完成 – 确定是否整体性能慢，还是某一个SQL导致（在pg_stat_activity中按照query_start排序，检查时间最长的SQL)  检查硬件和OS状态

率大约仅为 15%-17%，值得一提的是此论文主要由中国研发团队完成，也说明了中国研发团队实力处于世界一流水平。在论文 中 Greenplum 团队提出一种全新的全局死锁检测器来减少独占锁的使用，减少独占锁的使用可以极大的提高数据库 在高并发状态下的性能，这项技术已经在 Greenplum6 实现。 在 Greenplum6 和即将发布的 Greenplum 7, 带来了多项产品改 至关重要。锁是数据库中实现并发控制的重要技术，随之而来的死锁 处理。Greenplum 创新性的采用了分布式死锁检测，更新删除表的锁级别已降低，支持并发更新删除操作，大大提 升了处理性能。 并发控制优化 Greenplum 6 除了全局死锁检测，还引入了多项其他并发控制优化方法，这些优化对 SELECT 和 INSERT 提升比较 大。一个优化有关 procarray 锁，另一个优化和事务有关，大多数 没有必要的索引扫描 l 避免无用的堆截断尝试并在 VACUUM 期间采取独占锁定 l 提高 VACUUM 删除尾随空堆页面的速度 l 可以选择使用 SKIP_LOCKED 选项来跳过对无法立刻被锁的表进行 VACUUM 和 ANALYZE l 可以使用--jobs 选项并行进行 VACUUMDB 和 VACUUM；也支持—skip-locked Greenplum 集群多站点复制

数据仍然在数据⽂件中。 如何避免表膨胀 如何避免表膨胀 ⽅法⼀： ⽅法⼀：vacuum full table vacuum full不能回收索引的膨胀空间。 vacuum full 加载的锁与 DDL 锁类似，是排它锁。建议在没有业务的时候执⾏，不要堵塞业务。 使⽤ vacuum full 回收垃圾的建议操作流程： 1. 记录下表的索引 2. 删除索引 3. vacuum full 表 4. 重建索引 ⽅法⼆：通过修改分布键释放空间 表膨胀 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 135/206 修改分布键可以回收索引的膨胀空间。修改分布键加载的锁与 DDL 锁类似，是排它锁。建议在没有业务的时候执⾏，不要影响业务。 alter table test set with (reorganize=true) distributed randomly; alter

2017 年象行中国（杭州 站）第一期 Resource Queue • Deadlock – active_statements => ‘等待’ – SQL级并发控制 => 可能持有锁 – 拿着锁等待 => 环状等待 – Tx1: LOCK tbl; -- AccessExclusiveLock Tx2: INSERT INTO tbl; -- RowExclusiveLock, hang

41 Pivotal Confidential–Inter nal Use Only 备份恢复和并行copy Ÿ 重构gpbackup/gprestore – 不再锁pg_class表 – 普通表只加ACCESS SHARE锁 Ÿ 并行copy – COPY TO ON SEGMENT – COPY FROM ON SEGMENT

0 码力 | 44 页 | 8.35 MB | 1 年前

3

Greenplum备份恢复浅析

test_gp_dump_0_5_20170206160253.gz ? 2017 年象行中国（杭州 站）第一期 目前GP的并行备份，为了保证数据的一致性，有以下2步： 1. 给pg_class 加排他锁 2. 每个segment备份时设置隔离级别为串行化，保证每个 segment的数据一致性 但是，各个segment的数据设置隔离级别的动作存在时间差， 而master仍然接受新的事务，从而导致各个segment上的数

0 码力 | 17 页 | 1.29 MB | 1 年前

3

共 10 条

• 1

前往

页

相关搜索词

Greenplum特性在线扩容工具GPexpand剖析Database管理管理员指南分布布式分布式事务阶段提交协议混合负载理想数据平台Pivotal最佳实践分享完全兼容欧拉开源操作系统操作系统HTAP仓库数据仓库UDWUCloud中立计算服务服务商资源资源管理据库数据库架构分析功能备份恢复浅析