数据源的港湾

Oracle在修改数据前会把数据的旧值先写到undo表空间中以实现MVCC，而PG中的更新操作会被转换为delete+insert操作，然而这个delete并不是真正的把数据立刻删除掉，而是通过修改记录中的隐藏列来标记此行被删除，并在之后的某个时间通过后台任务来进行无效数据的清理。怎么理解呢，其实这些是相对Oracle的MVCC来说的，正如前面说的，Oracle的MVCC实现是把修改前数据存放在独立的undo表空间中，那么它就存在几个不足之处。当然了，PG的MVCC机制有好处，但它也是有坏处的。

如上面同学所示，可能是代码习惯不好，漏掉了参数的初始化，从而导致编译报错。为了帮助社区的同学一起看一下如何处理这个问题，于是请相关研发同学找了一个麒麟V10的环境尝试了一下，果不其然，遇到了相同的报错，报错内容完全一样。根据这位同学的说法，主要问题出在rand_heap_pages这个变量的地方，原话说的是“把这个变量的定义地方，初始化一下就行”很多同学已经忍不住想快速试用GP 7新版本了，同时，为了满足信创要求，需要在国产的操作系统服务器上运行GP。接着，我们再尝试重新编译，编译成功！

基于上述不同，体现在效率、功能等特性方面也大不相同。

特别是在关联时对于三大JOIN技术：hash join、merge join、nestloop join的支持，MySQL只支持最后一种nestloop join（未来会支持hash join），而多个大表关联分析时hash join是必备的利器，缺少这些关联功能非常致命，难以在OLAP领域充当大任。PG中contrib目录下的各个第三方模块，在GP中的postgis空间数据库、R、MADLIB、pycrypto各类加密算法、gptext全文检索都是通过这种方式实现扩展的。的，没有被大公司控制，

注：本文翻译自官网Greenplum数据库基于成本的优化器评估用于运行查询的许多策略，并选择成本最低的方法。与其他RDBMS优化器一样，在计算备选执行计划的成本时，Greenplum优化器会考虑要连接的表中的行数、索引的可用性和列数据的基数等因素。优化器还考虑数据的位置，它倾向于在段上执行尽可能多的工作，并尽量减少为完成查询而必须在段之间传输的数据量。当查询的运行速度低于预期时，您可以查看优化器选择的计划以及它为计划的每个步骤计算的成本。

本文描述YMatrix 5.1版本的安装过程，由于使用的操作系统为CentOS 7，具体步骤参考官网。

注：本文翻译自向Greenplum数据库段提供数据文件或从数据库段写入数据文件。

注：本文翻译自。

在GP环境中有时候我们会遇到“could not fork new process for connection: Cannot allocate memory” 这样的报错，有时可能是整个节点的segment都会宕机。那么有可能就是内存相关的参数配置有误。Greenplum是一个进程模型的MPP数据库，对内存的要求相对较高。Greenplum中也有一些关于内存如何合理配置的要求，包括官方文档。上次输出表示协调者配置243G，segment配置82G内存。永久修改总进程数 pid_max，使配置立即生效。

注：本文翻译自。

在Greenplum数据库段主机上，可用的主机内存在计算机上运行的所有进程之间共享，包括操作系统、Greenplum数据库段实例和其他应用程序进程。管理员必须确定哪些Greenplum Database进程和非Greenplum Database进程共享主机的内存，并配置系统以有效地使用内存。定期监视内存使用情况以检测Greenplum Database或其他进程使用主机内存的方式的任何变化也同样重要。

注：本文翻译自Greenplum数据库使用PostgreSQL多版本并发控制(MVCC)模型来管理堆表的并发事务。数据库管理系统中的并发控制允许并发查询以正确的结果完成，同时确保数据库的完整性。传统数据库使用两阶段锁定协议，防止事务修改已被另一个并发事务读取的数据，并防止任何并发事务读取或写入另一个事务已更新的数据。协调事务所需的锁会给数据库增加争用，从而降低整体事务吞吐量。Greenplum数据库使用PostgreSQL多版本并发控制(MVCC)模型来管理堆表的并发性。

注：本文部分翻译自gpcopy实用程序将对象从源Greenplum数据库系统中的数据库复制到目标Greenplum数据库系统中的数据库。

注：本文翻译自如果主协调器失败，则无法访问Greenplum数据库系统，并且WAL复制停止。使用gpactivatstandby激活备用协调器。激活备用协调器后，Greenplum Database在最后一次成功提交事务时重建协调器主机状态。这些步骤假定为系统配置了备用协调器主机。

本主题将指导您在一个或多个段或主机出现故障并希望恢复故障段时应采取的措施。注：增量恢复只有在将段恢复到当前主机(就地恢复)时才有可能。

注：本文翻译自启用段镜像后，当主段实例出现故障时，Greenplum Database会自动将故障转移到镜像段实例。如果每个数据部分都有一个段实例在线，用户可能不会意识到段已关闭。如果发生故障时，正在进行的事务回滚，并在重新配置的段集上自动重新启动。实用程序可用于标识失败的段。该实用程序显示来自目录表的信息，包括。如果整个Greenplum Database系统由于段故障而变得不可操作(例如，如果未启用镜像或没有足够的段在线访问所有用户数据)，则用户在尝试连接数据库时将看到错误。

针对这种情况，这样的文件可以直接删除即可，当然，为了保险起见，我们可以备份到一个别的目录。这意味着，某个对象的Oid和RelFileNode可能并不能完全对应起来，所以，当在磁盘目录中找到一个filenode，但从pg_class中找不到也是有可能的。另外，对于普通表，将对表执行truncate，vacuum full等操作后，会重写这个表的数据，也会引发这个表relfilenode值的变更。因此，针对这位同学的需求，既然已经从磁盘文件中找到对应占用空间大的oid，我们就可以通过以下语句找到对应的表。

后来，此同学不知用了什么方案，查询出来了gp_interconnect_type的值，已经修改为tcp模式了。不过在执行gpconfig -s gp_interconnect_type命令时同样会卡住，根据相关日志找到后台调用的SQL命令，使用相应的命令执行仍然卡住，截图如下。据这位同学说的是，虚拟机一重启，hosts就自动修改了，说是 华某云 的问题，希望 华某云能解决这个hosts自动修改的问题吧。查看/etc/hosts配置，发现同一个hostname既配置了特定的IP，也配置了127.0.0.1。

本文翻译自随着数据存储和云服务的爆炸式增长，数据现在以各种格式驻留在许多不同的系统中。通常，数据根据其位置、对数据执行的操作以及访问数据的频率进行分类:实时或事务性(热)、不太频繁(热)或存档(冷)。下图描述了一个数据源，它跟踪多年来每月的销售额。实时运行数据存储在MySQL中。分析和商业智能操作的数据存储在Greenplum数据库中。很少访问的归档数据驻留在AWS S3中。当外部系统中存在多个相关数据集时，远程连接数据集并只返回结果通常更有效，而不是协商执行相当昂贵的全数据负载操作的时间和存储需求。

注：本文翻译自Greenplum中的COPY命令用于在表和文件之间进行数据复制，可以将文件的数据写入到表中，也可以将表中的数据写出到文件。

注：本文翻译自gpinitsystem工具使用gpinitsystem_config文件中指定的配置参数初始化Greenplum数据库系统。

注：本文翻译自gpaddmirrors工具用于向未配置镜像的Greenplum数据库系统添加镜像segment。

说明一下，此问题是社区一位同学遇到的，据他描述是说机器在断电后再启动数据库，就启不起来了，然后在启动的过程中一直卡住。卡在了以下截图这里。听到是因为断电后导致的，怀疑是不是机器启动后自动打开了防火墙，但这个同学确说他部署的是一个单节点。在这个同学排查下，果然发现是/etc/hosts配置错误导致，问题解决。也是根据报错信息，从网上搜了一下相关解决方法，找到。从日志截图中，看到一些异常的信息，重点内容为。于是让他去看一下启动的日志，日志截图如下。这篇文章，说是和网络回环有关。所以，遇到错误不要慌，先看日志。

注：本文翻译自gpinitstandby工具用于为Greenplum Database系统添加和/或初始化备用协调器主机。

注：本文翻译自gpacttivatestandby工具用于激活备用协调器主机，并使其成为Greenplum数据库系统的活动协调器。

注：本文翻译自。

除了组镜像分布策略和散列镜像分布策略之外，用户还可以自定义镜像分布策略。有些基于Greenplum的数据库自己定义了额外的镜像分布策略，比如 YMatrix默认的镜像分布策略叫 环状镜像分布策略（Ring Mirroring）：即在至少有两台主机的情况下，将一个主机中的 Primary 序号序列看作一个一维纸带，从中间对折，然后在另外的主机上从对折的中间序号为起点，顺时针均匀排列 Mirror 到其他主机。扩容增加新的 Primary 不会影响之前已分布完成的镜像闭环，而是开启一个新的镜像环。

根据报错提示查看/sys/fs/cgroup/cpu/qbdb/发现此目录并不存在，因此说明cgroup并未配置。在QianBase MPP中希望从默认的资源队列模式修改为资源组模式，通过以下命令设置为资源组模式，通过以上输出已经能够找到/sys/fs/cgroup/cpu/gpdb/目录，说明配置成功。注：初次在执行这条命令时遇到以下报错信息，最后发现原因是因为qbadmin用户名写错导致。后续就可以继续尝试配置资源组并使用资源组功能了，我们在后续的文章中继续介绍。注：本文相关知识点可访问官方网站。

gp_segment_id是表中的隐藏列，用来标记该行属于哪个segment节点。因此可以基于该隐藏列进行分组查询，获取每个segment的记录数，从而判断表数据的分布是否均匀或有倾斜。gp_segment_configuration是一张系统表，它维护包括master、standby在内的所有节点信息。查看表的大小有两种方式，一种是\d+，一种是pg_size_pretty。如果想查看某一张表的size，可以使用pg_size_pretty，如下。可以在命令行使用show xxx来显示某个参数的值。

众所周知，Greenplum内部支持MVCC多版本并发控制，通过MVCC技术，可以支持同一行数据的读写并发问题，从而大大提升并发访问控制的能力。

我们在学习Greenplum的架构时知道，Greenplum中主要有Master管理层和Segment计算层。在高可用方面，Master通过配置一个Standby来实现主备，Segment则通过对实例设置镜像的方式也实现主备高可用（其中主实例称为Primary，备实例称为Mirror)。Master作为管理层，主要负责元数据的管理及执行计划的分发。为了存储元数据，Master节点上面有一个PG数据库实例，Standby节点上也同样有一个PG数据库实例，

注：本文章引自在前面的文章中，我们了解了单机库中的事务一致性实现以及分布式事务中的两阶段提交协议。大多数分布式系统都是采用了两阶段提交塄来保证事务的原子性，Greenplum也是采用了两阶段提交，Greenplum的两阶段提交是基于PostgreSQL的基础上实现的。

通过 URI 来。

恢复采用pg_restore命令，pg_restore命令只能恢复由pg_dump或pg_dumpall命令备份出来的压缩格式。串行备份是继承Postgresql的原生COPY命令，所有数据都经过Master处理。另外，gpbackup还支持增量备份，通过参数**–incremental**指定。–redirect-db代表恢复到不同的数据库名称。–backup-dir指定备份的目录。–jobs指定恢复表数据的并行连接数。–dbname代表备份的数据库名称。–jobs指定备份表的并行任务数。

在前面文章中，我们学习了Greenplum的几种表分布的策略，包括HASH分布、随机分布、复制表三种分布策略。表的分布策略可以实现表的数据能否均匀的分布在不同的Segment实例中。除了表的分布策略以外，Greenplum还支持对表进行分区。分区是在每个Segment内部的行为，将表创建为分区表后，表会拆分为ROOT表和子分区表，数据都存放在子分区表中，ROOT表不存储数据。Greenplum中的分区有两种方式：list（列表）分区及range（范围）分区。这两个分区方式可以随意组合形成多级分区。

Greenplum中所有的表都是必须分布存放的，这样可以充分利用MPP的并发特性。在创建表时可以指定不同的分布策略，包括三种分布策略：HASH分布、随机分布和复制表。概念：选择一个列或多个列作为数据表的分布键，通过hash计算，将插入的数据路由到特定的segment上。HASH分布是默认的分布策略。也可通过指定DISTRIBUTED BY语法来指定使用HASH分布。注：当建表时未定义分布键时，如果表有主键，使用主键字段作为默认的分布键；如果表上没有主键，默认按照第一个字段来分布。示例：随机分布概念

在学习Greenplum的过程中，了解到Greenplum中表有多种不同的存储模式，包括堆表、AO表、行存、列表、压缩、加密这些特性，这些不同的存储模式分别适用什么样的场景，我们在真正使用的时候又该怎么合理的选择哪一种表呢？本文就GP中的这几种表的存储模式加以说明。