采用“PostgreSQL技术路线+集中式存储”平滑替换Oracle后如何开展IT架构高效运维？|《迈向YB数据时代》
采用“PostgreSQL技术路线+集中式存储”平滑替换Oracle后如何开展IT架构高效运维？|《迈向YB数据时代》
talkwithtrend
talkwithtrend.com社区（即twt社区）官方公众号，持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群，让您时刻和国内企业IT同行保持信息同步。
实施“PostgreSQL技术路线+集中式存储”方案平替Oracle后，如何从运维角度，妥善解决监控、备份恢复、日常维护、性能优化、故障分析定位、应急处置、运维人员技术转型等方面的难点是本次议题关注的焦点。
本期为大家带来 《迈向YB数据时代》 2023年春季刊“精细运营 ”栏目 中的 议题二 ：
采用“PostgreSQL 技术路线 + 集中式存储”平滑替换 Oracle 后如何开展 IT 架构高效运维？
尽管PostgreSQL技术方案在解决Oracle数据库所带来的问题方面取得了显著成效，但在实际的运维过程中，还是遇到了数据库的监控、性能优化、故障处理以及运维人员的技术转型等问题。在使用“PostgreSQL技术路线+集中式存储”替换Oracle后，运维工作需要时刻保持关注数据库的性能、安全性和可靠性。通过实时监控、备份、优化、故障排除等一系列方法并保持持续学习，才可以高效地管理和运维PostgreSQL 数据库。
一、背景
随着企业业务的不断发展，数据库作为数据的重要存储和管理工具，扮演着至关重要的角色。在数据库技术方面，Oracle数据库作为市场上应用广泛、技术成熟、运维稳定的数据库之一，受到了很多企业的青睐。然而，Oracle数据库的高昂的授权和运维成本，也成为了企业使用Oracle数据库的瓶颈。在这种情况下，越来越多的企业开始转向采用PostgreSQL技术方案，以解决上述问题。本文将以电信运营商企业的应用案例为背景，探讨在采用“PostgreSQL技术路线+集中式存储”方案平替Oracle数据库后，如何开展IT架构高效运维。
二、电信运营商企业采用 “PostgreSQL技术路线 + 集中式存储” 平滑替换Oracle 实践概述
电信运营商作为一个涵盖互联网、通讯、IT等众多领域的综合性企业，对数据的存储、处理和分析有着严格的要求。物联网系统是电信运营商实现集中业务受理、计费批价、实时诊断、生命周期管理等能力的综合性业务支撑系统，也是对Oracle数据库使用最广泛、依赖程度最高的系统之一，但在物联网业务规模和数据量不断增长的情况下，Oracle数据库高昂的授权和运维成本、复杂的许可证模式以及扩展性不足等问题逐渐凸显出来，给企业带来了巨大的负担和压力。
为了解决这些问题，本项目开始探索能替代Oracle的技术方案，经过一段时间的选型和测试，最终数据库采用了“PostgresSQL+集中式存储”的技术方案，利用其开源免费、高可用、可扩展、高可靠等优点，替代Oracle数据库。
原Oracle数据库方案使用本地盘存储数据，通过Active DataGuard技术在同机房部署实时的只读备库，防止主库的单点故障导致服务不可用或者数据丢失。在新的PostgreSQL方案中，我们采用了三节点架构，其中包括一台主库、一台同步备库和一台异步备库，数据库存储方面则选择集中式存储，不仅实现对数库存储的集中式管理和维护，而且相对于oracle的本地存储有更好的性能和更高的可靠性。该方案在不影响主库性能的情况下，最大程度的保障了服务的可用性。
三、采用 PostgreSQL 技术方案平替Oracle 数据库后的运维难点
尽管PostgreSQL技术方案在解决Oracle数据库所带来的问题方面取得了显著成效，但在实际的运维过程中，还是遇到了很多的难点问题。这些问题主要包括数据库的监控、性能优化、故障处理以及运维人员的技术转型等。
3.1 数据库监控
Oracle不仅拥有非常完善的数据库生态，其监控工具丰富且功能强大，比较常见的如OracleEnterprise Manager，MaxGauge，ShinDataDMP等，而且Oracle内部提供了丰富的动态性能视图供DBA用来监控和诊断问题。在采用PostgreSQL技术方案平替Oracle数据库后，对数据库的监控主要有如下几个挑战：
多样性和复杂性： PostgreSQL数据库生态系统中存在多种监控工具，每个工具都有不同的功能和特点。这使得选择适合特定需求的监控工具变得复杂，并且需要花费时间和资源来评估和比较不同的选项。
缺乏统一的解决方案： 目前，没有一个通用的、全面的、一体化的监控解决方案可以满足所有的PostgreSQL数据库监控需求。这可能导致企业需要组合使用多个不同的工具和技术来实现全面的监控，增加了部署和维护的复杂性。
复杂的配置和部署： 某些监控工具在配置和部署方面可能存在一定的复杂性，比如需要安装各种插件，特别是对于非专业的数据库管理员来说。这可能需要一些专业知识和技能，以确保正确配置和有效使用监控工具。
监控数据的实时性和准确性： 对于大规模的生产环境，实时性和准确性是数据库监控的重要需求。然而，某些监控工具可能面临数据采集和处理的延迟，导致监控数据的实时性和准确性受到影响。
高级功能和自定义需求的支持： 某些高级功能和自定义需求可能无法由通用的监控工具满足。这可能需要企业进行定制开发或选择专业的高级监控工具来满足特定的监控需求。
PostgreSQL数据库与Oracle数据库有着不同的架构和监控指标，因此需要进行相应的调整和优化。
3.2 故障定位分析
在进行PostgreSQL数据库故障定位和分析时，通常面临以下难点：
复杂的系统架构： PostgreSQL数据库通常在复杂的高可用架构中运行，涉及多个组件和服务，如patroni,repmagr，pgpoll-II等。当故障发生时，需要跨多个层面进行定位，包括操作系统、网络、硬件和数据库本身。这增加了故障定位的复杂性。另外集中式存储相对于本地存储来说，其IO链路更为复杂。例如，本地存储出现故障或性能问题时，通常只需要排查磁盘的问题，而使用集中存储发生故障或性能问题，则需要从磁盘、控制器、交换机、光纤线以及HBA卡等多个环节进行排查，这无疑对故障处理带来了更多困难。
错误信息不明确： 有时故障可能没有明确的错误信息或警告，而只是表现为性能下降、响应延迟或异常行为。在这种情况下，需要进行更深入的分析和调查，以确定故障的原因。
故障难以复现： 有时故障可能是间歇性的，不易复现。在没有明确的复现场景的情况下，定位问题会变得更加困难。需要通过日志分析、性能监控等手段来获取更多的信息，以尽可能精确地复现故障。
缺少完善的知识库： PostgreSQL数据库并没有完善的知识库体系，而通过社区、论坛等途径获得的故障解决方案往往准确性较低，这给运维人员在定位问题时带来比较大的困扰。
3.3 性能优化
相比于已经成熟的Oracle数据库，PostgreSQL数据库本身缺少相关的性能视图，性能问题诊断主要依赖数据库日志、会话信息以及DBA的经验。在性能优化方面的难点主要体现在以下几点：
查询复杂： PostgreSQL支持强大的查询功能，包括复杂的联接、子查询、聚合等。优化这些复杂查询的执行计划和性能是一个挑战，需要深入了解查询优化器的工作原理以及数据库的统计信息等。
优化手段缺乏： PostgreSQL数据库不支持手动执行计划。
统计信息的收集： PostgreSQL使用统计信息来评估查询计划，统计信息的准确性对于优化器的决策至关重要。收集和更新统计信息需要根据数据的变化和访问模式进行定期维护否则可能导致错误的查询计划选择和性能下降。对于不同类型的业务系统来说，难点在于怎么将统计信息收集的效率和对性能的影响程度维持在一个合理值。
资源管理和调优： PostgreSQL在处理大规模并发和高负载时需要进行有效的资源管理和调优。这涉及到内存管理、磁盘IO优化、并发连接控制、查询并行处理等方面的挑战，需要细致的配置和监控。
3.4 运维人员技术转型
采用PostgreSQL技术方案平替Oracle数据库后，企业需要考虑运维人员技术转型的问题。 Oracle数据库和PostgreSQL技术方案有着不同的架构和技术特点，且PostgreSQL是开源的，其代码和错误日志可以自由访问。在遇到故障时，运维人员可以通过查看错误日志、调试代码等方式来进行故障分析和定位,因此也对运维人员的代码能力有更高的要求，以适应新的技术环境。此外，企业还需要考虑到运维团队的人员组成和培养计划，以确保运维团队的技术水平和能力。
四、如何解决采用“PostgreSQL 技术路线 + 集中式存储”方案替换 Oracle后带来的问题
4.1 监控方案
使用“PostgreSQL技术方案+集中式存储”平替Oracle数据库后，需要重新设计数据库监控系统，为充分利用PostgreSQL开源的特性，我们同样采用了开源的Prometheus+Grafana监控方案。
数据采集： 数据库主机部署postgres_exporter端点程序，该程序目前支持PG10至PG15版本，提供了针对PostgreSQL数据库运行状态、资源使用、会话信息、查询性能、高可用等方面的上千个指标。而集中式存储端则内置了Prometheus监控端点，可以直接将存储设备的采集数据推送到prometheus。其数据采集包含存储的设备及磁盘状态、空间容量、IO性能、数据备份、设备日志等全方面的监控数据。
监控配置： 安装Prometheus服务，在Prometheus的配置文件（prometheus.yml）中添加数据库、存储设备的监控目标，指定相应的IP地址、端口和监控路径。并可以在配置文件中对采集到的指标进行过滤处理，避免无效指标数量太多影响采集性能。
数据可视化和查询： 使用Prometheus的内置查询语言（PromQL）来查询和分析存储设备的指标数据。使用Grafana来可视化监控数据，创建仪表板和报告，grafana提供了丰富的图表、仪表板和面板选项。可以根据自己的需求创建定制化的监控仪表板。
告警和通知： Grafana支持灵活的警报设置和通知机制，用户获取到关键指标的状态及数据变化后，可以通过自定义规则判断是否触发告警，并支持告警表达式和告警阈值的灵活调整，另外grafana支持目前主流的短信、邮箱、微信等通知方式。
4.2 故障定位分析
对于PostgreSQL数据库故障的快速定位分析，一方面，运维人员应该提高阅读和调试源码的能力，相比于非常成熟的商业数据库Oracle，PostgreSQL在故障诊断方面并没有现成的故障分析工具，所以对于根据现有的错误信息不能准备定位故障原因的情况，应该借助PostgreSQL源码进行分析。另一方面，应该建立公司内部的知识库体系，完善的知识库应该包括数据库安装配置，高可用、监控、管理、故障诊断等多个方面的内容。这将极大的提升同类故障的定位及处理效率。
4.3 优化方案
性能优化是数据库运维中非常重要的一环。无论多么强大的数据库，在遇到配置不合理或大量低效SQL的时候也会变得无计可施，所以持续的性能优化是用好数据库的关键，在采用PostgreSQL技术方案平替Oracle数据库后，企业需要重新制定性能优化策略和方法，并且要针对不同的业务场景进行相应的调整。主要有以下措施：
1) 配置标准化： 制定标准的数据库配置方案，跟据业务特点，通过业务测试、压力测试等手段在上线前对数据库进行最优配置，其中包括硬件配置，操作系统配置，参数配置。如：
主机电源管理模式设置为最大可用模式；
主机CPU禁用超线程；
主机内存关闭NUMA；
操作系统层开启大页；
操作系统层禁用透明大页；
数据库层开启归档等。
2) 定制统计信息收集策略： 根据业务特点、数据量级、服务器性能等信息，结合自动化运维工具或者定时任务手段，定制统计信息的收集策略。
3) 定期进行维护： 定期进行数据库维护任务，如统计信息更新、索引重建、数据清理和压缩等，以保持数据库的健康状态。定期进行性能测试和基准测试，评估数据库的性能和稳定性，并寻找改进的机会。
4.4 运维人员技术转型
运维人员完成从Oracle到PostgreSQL的技术转型是一个漫长的过程，但是可以通过以下方式持续学习，加速转型：
1) 系统性培训： 对运维人员进行系统的PostgreSQL数据库技术培训，深入学习PostgreSQL的体系结构、特性、语法和管理工具等方面的知识。可以通过阅读官方文档、参加培训课程、研究相关书籍和在线教程等方式获取必要的知识基础。
2）运维工作前置： 对于在向PostgreSQL数据库技术的转型阶段，运维人员不能局限于数据库运维阶段，而应该在数据库选型、业务测试、压力测试、业务适配、数据迁移、切换上线等各个阶段介入，这样才能更加全面掌握PostgreSQL数据库的知识体系，为后续的运维工作奠定基础。
3）团队协作： 技术转型需要团队的合作和支持。运维人员可以组织内部培训和知识分享会，促进团队成员之间的相互学习和交流。鼓励团队成员共同探讨和解决问题，建立良好的技术交流和合作氛围。
五、结语
韩丹 邮政储蓄银行管理架构师：
“PostgreSQL技术路线+集中式存储”替换Oracle是一种有效的开源替代方案，其中的高效运维需要关注性能优化、安全保障、可靠性保障和自动化运维等方面。通过合理规划硬件资源、优化数据库参数、优化SQL语句、建立完善的备份和恢复机制、建立高可用架构、编写自动化脚本等手段，可以提高PG数据库的性能和可靠性，降低运维成本。
一、引言
为什么要探讨这个问题？
随着数据量不断增长，企业对于数据库的需求也越来越高。Oracle数据库作为一款知名而成熟的商业数据库，虽然有着出色的性能和可靠性，但是在成本、许可证、增值服务等方面存在不小的问题。因此，越来越多的企业开始采用“PG技术路线+集中式存储”平替Oracle，以降低开销并达到更高的数据存储和管理效率。
由于PostgreSQL和Oracle在功能和使用方式上存在差异，因此在采用“PG+集中式存储”替换Oracle的过程中，需要考虑运维的改造，在运维人员技能、运维流程和工具、安全性管理等方面以确保新系统的稳定性和可靠性。
总体来说，在运维过程中，运维人员需要了解 PostgreSQL 和 Oracle 的不同特点，从而采用不同的策略来保证系统的运行稳定性和安全性。
二、“PostgreSQL 技术路线 + 集中式存储”替换 Oracle 的优势
开源免费： PostgreSQL技术路线+集中式存储方案不会产生过高的许可证费用，相对而言，它是开源和免费的。这可以减轻压力并节省IT成本。
高度可扩展： PostgreSQL数据库采用了很多创新的技术，可以支持大规模数据集，管理大规模数据。此外，它还具有很多可扩展的功能，可以满足不同业务的需求。
容易使用： PostgreSQL借鉴了Oracle的一些经验，因此在使用上比其他数据库方便。并且，它支持直接上线升级，最大程度地减少了停机时间。
费用较低： 相较于Oracle的许可证费用，PostgreSQL基本上是免费的。虽然在使用过程中可能会发生其他费用，但总体来说PG的成本更低。
丰富的社区支持： PostgreSQL是一种受欢迎且广泛使用的数据库，有很多社区和开源组织开发和支持它，这为使用者提供了更广泛的软件支持和技术支持。
三、“PostgreSQL 技术路线 + 集中式存储”替换 Oracle 的 IT 架构高效运维的准备事宜
深入熟练掌握PostgreSQL技术：在转向PostgreSQL数据库之前，需要对PostgreSQL技术有足够的了解和熟悉，以方便管理、迁移数据以及进行应急处理。
数据迁移策略： 从Oracle数据库迁移到PostgreSQL数据库，迁移过程中要确保数据的完整、稳定和安全。需要考虑数据迁移的方法、迁移的时间、业务的可用性、数据的一致性等方面的问题，以确保数据无缝迁移。
统一的数据管理策略： 集中式存储方案是一种高效的数据管理方式，需要对所有存储的数据进行统一管理，例如：规范数据、清洗数据、备份和恢复等。
安全人员培训： PostgreSQL数据库的安全架构与Oracle数据库不同。企业需要在转型过程中加强安全培训和管理，以实现更好的信息安全保障。
运维工具的选择： 以“PG技术路线+集中式存储”平替Oracle为例，“集中式存储”需要考虑数据的大规模的存储管理以及存储的安全性等问题。在这方面，需要选择合适的运维工具，以保证数据管理的高效、安全和稳定。
不断改进优化： 在转型过程中，需要不断地改进和优化，以符合企业的专业需求。同时，需要关注PG数据库更新的版本和补丁，及时升级并保证其可用性和稳定性。
四、“PostgreSQL 技术路线 + 集中式存储”平替 Oracle 的 IT 架构高效运维实施
概括的说，PG数据库的运维需求分为五个方面，日常监控、故障预警、自动化巡检、性能优化和故障诊断。
4.1 日常监控
主要包括满足日常监控数据库所需，了解数据库运行总体状态，专项护航使用，关键系统值守工具。
对于日常的监控，我们采用了 可视化的集成的运维系统，通过内置运维工具随时了解数据库实例的总体运行状态。
运维系统通过不定时采集分布于各个节点的数据库状态，总体展示数据库日常运行情况。采集的参数指标包括：
表1：日常监控参数指标
“日常监控”是一个十分有效的自动化运维工具，每天半夜针对数据库的运行数据以及一些规则自动做分析，并形成言简意赅的日检总结报告，运维人员上班后直接阅读这些报告就可以了解自己运维的数百个数据库实例中存在的一些常见问题，从而可以确定当天或者近期是否需要对某些数据库实例做相应的变更。
4.2 故障预警
故障预警主要还是集中在硬件和主从同步上面，通过埋点采集数据库的运行状态，当出现例如流复制阻塞，数据库集群中服务器异常，磁盘和内存等有异常的时候，将相关信息发送至自建的监控平台，在监控大屏幕中以高亮显示，并以短信形式通知到对应的系统的运维人员。此外海量的告警信息会让预警变得毫无意义。因此构建了基于故障模型的“运维经验告警”。通过专家经验与以往的经验构建的复杂的规则发出更精准的预警，也能让告警产生后，运维人员可以更加快速的定位问题，消除隐患。
我单位在实际的运维过程中，对于存储的物理故障，利用成熟可靠的企业存储提供的API或SNMP协议，能够全方位的实时监控磁盘温度、电压、功率、性能等，实现大规模磁盘的监控及慢盘的检测，提前发现IO Hang等问题。并在监控工具中，可以设置阈值告警，并根据不同级别的告警类型，实现邮件或短信通知相应的运维人员。
针对系统层面的磁盘/内存性能，监控工具中使用Prometheus+Grafana，收集系统层面的指标数据，并通过可视化界面展示出来。 同时也可以设置阈值告警和通知。 先安装并配置Prometheus以收集例如大量系统级别的指标数据，包括磁盘和内存性能数据。 然后配置Prometheus的exporters以获取更详细的指标数据。 例如： 可以使用Node Exporter来获取更多关于服务器的指标数据。 后续利用创建Grafana仪表板来显示磁盘和内存性能指标。 在Grafana中，可以使用Prometheus作为数据源来创建各种类型的图表和仪表板。
通过在Grafana中设置警报以及可视化，快速了解系统是否出现问题。并可以基于阈值或其他条件进行设置报警，以通知管理员或团队，减少运维压力。
4.3 自动化巡检
自动化巡检，还是通过前期的内置脚本，形成每天必备的健康检查内容，对数据库进行相关的自动化检测。及时发现相关问题，避免发生故障事件。包括PG数据库集群状态是否正常，有无超过5S长SQL,有无锁等待及索引失效情况。
自动化巡检与日常监控相比，更加靠近于应用问题的快速排查。和发现系统隐患，防患于未然。
4.4 性能优化
对于日常监控和自动化巡检中发现的长时长的SQL语句，自动流转到性能优化人员，通过事先安装的auto_explain在数据库日志中记录下对应的执行计划，有针对性的对相关语句进行优化。同时在执行计划中对应用设计和软件本身进行适应性调整。
4.5 故障诊断
故障诊断的能力，能够快速准确地发现和解决问题，以保证系统的稳定性和可靠性。做到这一点是一个综合性工作。包括以下很多方面。
4.5.1 故障诊断的措施
监控系统是数据库运维中非常重要的一环，能够实时监测数据库的状态，及时发现异常情况，提高故障诊断的效率。常见的监控指标包括CPU负载、磁盘空间、内存使用率、网络带宽等。
日志记录是故障诊断的重要手段之一，可以记录数据库运行过程中的各种事件和错误信息，为后续的故障诊断提供有力的依据。PG数据库支持多种日志记录方式，包括文本日志、CSV日志、syslog等。
备份和恢复是保证数据库可靠性和数据安全的重要措施，也是故障恢复的关键手段。PG数据库支持多种备份和恢复方式，包括基于文件系统的备份、基于二进制日志的备份、基于归档日志的备份等。同时建议和集中式存储的企业级备份恢复能力结合，通过集中式存储的快照克隆能力提升备份/恢复的性能。
4.5.2 故障诊断的方法
故障排查，主要包括以下步骤：
1) 收集信息：收集相关的日志、监控数据和用户反馈等信息，了解故障发生的时间、地点、影响范围等。
2) 排除可能性：根据收集的信息，逐一排除可能导致故障的各种原因，如硬件故障、网络故障、配置错误等。
3) 分析问题：对剩余的可能原因进行分析和研究，找到故障的根本原因。
4) 解决问题：根据分析结果，采取相应的措施解决故障，如修改配置、修复代码、更换硬件等。
性能分析也是故障诊断的常用方法之一，通过对数据库运行过程中的各种指标进行分析和优化，提高系统的性能和稳定性。常用的性能分析工具包括pg_stat_statements、pgBadger、pgFouine等。
数据库监控 数据库监控是实时了解数据库运行情况的方法，可以帮助运维人员快速发现和解决问题。常见的数据库监控工具包括Zabbix、Nagios、Cacti等。
4.5.3 常见的PostgreSQL数据库故障诊断的工具
pgbouncer：一款轻量级的连接池工具，可以提高数据库的性能和可靠性，还可以通过统计信息和日志记录来帮助故障诊断。
pgadmin126459646：一款用于管理和监控PG数据库的图形化界面工具，可以实时监测数据库的状态、执行SQL语句、备份和恢复数据库等操作，还可以通过日志记录和统计信息来帮助故障诊断。
pgbadger：一个用于分析PG数据库日志的工具。
Nagio：一个开源的网络监控系统，支持对PG数据库进行监控。
五、结语
通过议题讨论，我们发现“PostgreSQL技术路线+集中式存储”方案平替Oracle数据库是一种有效的替代方案，但在实际的运维工作中需要时刻保持关注数据库的性能、安全性和可靠性。通过合理规划硬件资源、优化数据库参数、优化SQL语句、建立完善的备份和恢复机制、建立高可用架构、编写自动化脚本等手段，以提高PostgreSQL数据库的性能和可靠性，降低运维成本。
阅读更多《迈向YB数据时代》精彩内容，请识别以下二维码：
《迈向YB数据时代》
更替Oracle数据库项目是多个行业2023的排名前三的应用趋势项目。用户反馈更替需求中，不管来自城商行的用户，省农信用户、证券基金用户，甚至是容器化进程最快的保险行业等用户，平替Oracle才是当前最核心最紧迫需求。希望社区聚焦服务如何平替Oracle，服务内容从架构到技术路线，具体产品选型，以及关系到数据安全稳定的存储如何选择。
《迈向YB数据时代》 2023春季刊 为社区展开一系列平替需求下的用户服务正式拉开帷幕，本期的主题为“平替Oracle”架构下的存储应用。期待读者可以从应用场景、到架构、到解决方案，到落地，到运维，到人才培养等多个角度，通过群体专家的力量，在多个核心议题中产生共鸣，获得一定的决策参考。
-
2023年春季刊【最佳实践】议题二： 如何架构设计自主可控数据库两地三中心容灾方案？
-
2023年春季刊【惊喜运营】议题一： 采用“PostgreSQL技术路线 + 集中式存储”平滑替换Oracle，应用和基础架构运维如何改造？
*本公众号所发布内容仅代表作者观点，不代表社区立场