Greenplum 数据库最佳实践(2)

使用所有您可用的工具，以了解系统不同负载下的表现。 检查任何不寻常的事件并确定原因。

通过定期运行解释计划监控系统查询活动，以确保查询处于最佳运行状态。 检查查询计划，以确定是否按预期使用了索引和进行了分区裁剪。

了解系统日志文件的位置和内容，定期监控日志文件，而不是在出现问题时才查看。 详见系统监控和维护以及监控GPDB日志文件。（后续章节) ANALYZE

不要对整个数据库运行 ANALYZE，只对需要的表运行该命令。 建议数据加载后即刻运行 ANALYZE。

如果INSERT、UPDATE 和 DELETE 等操作修改大量数据，建议运行 ANALYZE。 执行 CREATE INDEX 操作后建议运行 ANALYZE。

如果对大表ANALYZE耗时很久，则只对JOIN字段、WHERE、SORT、GROUP BY 或 HAVING 字句的字段运行 ANALYZE。 详见使用ANALYZE更新统计信息。（后续章节) Vaccum

批量 UPDATE 和 DELETE 操作后建议执行 VACUUM。

不建议使用 VACUUM FULL。建议使用 CTAS（CREATE TABLE...AS）操作，然后重命名表名，并删除原来的表。

对系统表定期运行 VACUUM，以避免系统表臃肿和在系统表上执行 VACUUM FULL 操作。 禁止杀死系统表的 VACUUM 任务。 不建议使用 VACUUM ANALYZE。

详见消除系统表臃肿。（后续章节) 加载

使用 gpfdist 进行数据的加载和导出。 随着段数据库个数的增加，并行性增加。 尽量将数据均匀地分布到多个 ETL 节点上。

将非常大的数据文件切分成相同大小的块，并放在尽量多的文件系统上。 一个文件系统运行两个 gpfdist 实例。 在尽可能多的网络接口上运行 gpfdsit。

使用 gp_external_max_segs 控制访问每个 gpfdist 服务器的段数据库的个数。 建议gp_external_max_segs的值和 gpfdist 进程个数为偶数。 数据加载前删除索引；加载完后重建索引。 数据加载完成后运行 ANALYZE 操作。

数据加载过程中，设置 gp_autostats_mode 为 NONE，取消统计信息的自动收集。 若数据加载失败，使用 VACUUM 回收空间。 详见加载数据。（后续章节) gptransfer

为了更好的性能，建议使用 gptransfer 迁移数据到相同大小或者更大的集群。

避免使用 --full 或者 --schema-only 选项。建议使用其他方法拷贝数据库模式到目标数据库，然后迁移数据。

迁移数据前删除索引，迁移完成后重建索引。

使用 SQL COPY 命令迁移小表到目标数据库。 使用 gptransfer 批量迁移大表。

在正式迁移生产环境前测试运行 gptransfer。试验 --batch-size 和 --sub-batch-size 选项以获得最大平行度。如果需要，迭代运行多次 gptransfer 来确定每次要迁移的表的批次。 仅使用完全限定的表名。表名字中若含有点、空格、单引号和双引号，可能会导致问题。 如果使用 --validation 选项在迁移后验证数据，则需要同时使用 -x 选项，以在源表上加排它锁。

确保在目标数据库上创建了相应的角色、函数和资源队列。gptransfer -t 不会迁移这些对象。 从源数据库拷贝 postgres.conf 和 pg_hba.conf 到目标数据库集群。 使用 gppkg 在目标数据库上安装需要的扩展。 详见使用 gptransfer 迁移数据（后续章节) 安全

妥善保护 gpadmin 账号，只有在必要的时候才能允许系统管理员访问它。

仅当执行系统维护任务（例如升级或扩容），管理员才能以 gpadmin 登录Greenplum集群。 限制具有 SUPERUSER 角色属性的用户数。GPDB中，身为超级用户的角色会跳过所有访问权限检查和资源队列限制。仅有系统管理员具有数据库超级用户权限。参考《Greenplum数据库管理员指南》中的“修改角色属性”。

严禁数据库用户以 gpadmin 身份登录，严禁以 gpadmin 身份执行ETL或者生产任务。 为有登录需求的每个用户都分配一个不同的角色。 考虑为每个应用或者网络服务分配一个不同的角色。 使用用户组管理访问权限。 保护好 ROOT 的密码。

对于操作系统密码，强制使用强密码策略。 确保保护好操作系统的重要文件。 详见安全。（后续章节) 加密

加密和解密数据会影响性能，仅加密需要加密的数据。 在生产系统中实现任何加密解决方案之前都要做性能测试。

GPDB生产系统使用的服务器证书应由证书签名颁发机构（CA）签名，这样客户端可以验证服务器。如果所有客户端都是本地的，则可以使用本地CA。 如果客户端与GPDB的连接会经过不安全的链路，则使用 SSL 加密。

加密和解密使用相同密钥的对称加密方式比非对称加密具有更好的性能，如果密钥可以安全共享，则建议使用对称加密方式。

使用 pgcrypto 包中的函数加密磁盘上的数据。数据的加密和解密都由数据库进程完成，为了避免传输明文数据，需要使用 SSL 加密客户端和数据库间的连接。 数据加载和导出时，使用 gpfdists 协议保护 ETL 数据安全。 详见加密数据和数据库连接。（后续章节) 高可用

使用8到24个磁盘的硬件RAID存储解决方案。 使用RAID1、5或6，以使磁盘阵列可以容忍磁盘故障。

为磁盘阵列配备热备磁盘，以便在检测到磁盘故障时自动开始重建。 在重建时通过RAID卷镜像防止整个磁盘阵列故障和性能下降。 定期监控磁盘利用率，并在需要时增加额外的空间。

定期监控段数据库倾斜，以确保在所有段数据库上数据均匀分布，存储空间均匀消耗。 配置备用主服务器，当主服务器发生故障时由备用主服务器接管。

规划好当主服务器发生故障时如何切换客户端连接到新的主服务器实例，例如通过更新DNS中主服务器的地址。

建立监控系统，当主服务器发生故障时，可以通过系统监控应用或电子邮件发送通知。 分配主段数据库和其镜像到不同的主机上，以防止主机故障。

建立监控系统，当主段数据库发生故障时，可以通过系统监控应用或电子邮件发送通知。 使用 gprecoverseg 工具及时恢复故障段，并使系统返回最佳平衡状态。 在主服务器上配置并运行 gpsnmpd 以发送 SNMP 通知给网络监控器。

在 $Master_DATA_DIRECTORY/postgresql.conf 配置文件中设置邮件通知，以便检测到关键问题时，Greenplum 系统可以通过电子邮件通知管理员。 考虑双集群配置，提供额外的冗余和查询处理能力。

除非Greenplum数据库的数据很容易从数据源恢复，否则定期备份。

如果堆表相对较小，或者两次备份之间仅有少量AO或列存储分区有变化，则使用增量备份。 如果备份保存在集群的本地存储系统上，则备份结束后，将文件移到其他的安全存储系统上。 如果备份保存到 NFS 中，则建议使用像 EMC Isilon 这样的可扩展 NFS 方案以防止I/O瓶颈。 …… 此处隐藏：1423字，全部文档内容请下载后查看。喜欢就下载吧 ……