二者在成本结构上，云部署初始成本低、按需付费，但长期可能费用累积；本地部署初始投入高、运维负担重，长期单位成本或更低。数据安全方面，云部署依赖服务商专业防护，合规便利却有潜在交叉访问风险；本地部署能自主掌控安全边界，却需应对内部管理漏洞。运维管理上，云部署自动化便捷但难适配特殊流程，本地部署高度定制却运维复杂。 云部署和本地部署有啥区别？ 一、成本结构：短期支出与长期投入的博弈云部署：轻资产运营模式初始成本低：无需采购服务器、存储设备等硬件，初期投入可降低80%以上。按需付费：根据业务需求灵活调整资源，避免资源闲置浪费。隐性成本减少：云服务商负责硬件维护、系统升级和电力消耗，企业无需承担相关费用。潜在风险：随着业务规模扩大，订阅费用可能累积超过本地部署的总拥有成本（TCO）。本地部署：重资产投入路径初始投入高：需一次性投入数十万至数百万用于硬件采购、机房搭建及网络配置。持续运维负担：年均维护成本约占初始投入的20%-30%，且需专职IT团队支持。长期优势：对于稳定运行5年以上的系统，单位成本随时间推移逐渐低于云部署。二、数据安全与合规：控制权与专业能力的权衡云部署：依赖服务商的安全体系专业防护：主流云厂商提供AES-256加密、多地容灾备份及三级等保合规支持，数据可靠性达99.99%。合规便利性：自动满足GDPR、等保2.0等法规要求，减少企业合规人力投入。潜在顾虑：数据存储于第三方平台，存在理论交叉访问风险；部分行业受法规限制需谨慎选择。本地部署：自主掌控的安全边界物理隔离优势：数据完全存储于企业内部服务器，通过自定义防火墙和物理隔离网络实现零外部暴露。主权明确性：避免第三方介入风险，尤其适合金融、医疗等强监管行业。内部挑战：约60%的数据泄露源于内部管理漏洞，需企业自行承担安全责任。三、运维管理：自动化便捷性与定制化需求的冲突云部署：自动化运维提升效率快速响应：资源申请到上线仅需数小时，支持弹性伸缩应对流量高峰。集中管控：通过Web界面统一管理多地域资源，自动完成系统升级与故障替换。局限性：标准化服务难以适配特殊业务流程，网络中断可能导致业务停摆。本地部署：高度定制但运维复杂深度集成：支持与ERP、OA等现有系统无缝对接，适应制造业生产控制、政府涉密网络等场景。离线可用：不依赖互联网，保障金融交易、实时数据采集等业务的连续性。运维挑战：需自建技术团队处理硬件巡检、软件更新及故障排查，人力成本居高不下。决策框架：四步锁定最佳方案第一步：业务特性分析评估业务的数据敏感性、合规要求、流量特征预测未来1-3年的业务增长轨迹和可能的波动性第二步：技术能力评估客观分析现有技术团队的技能结构和人员规模评估企业在安全、运维方面的投入意愿和能力第三步：财务模型测算计算3-5年总体拥有成本，而不仅仅是初期投入评估企业的现金流状况和投资偏好第四步：混合模式考量对于大多数中型以上企业，混合架构正在成为新标准：将核心敏感系统保留在本地，将面向互联网的波动性业务部署在云端。这种模式既保障了关键数据的控制权，又获得了云端的弹性优势。小库主机小编温馨提示：云部署与本地部署并非非此即彼的单选题，而是各有优劣的技术路径。明智的决策者应该超越概念争论，基于企业具体的业务需求、技术实力和财务现状，选择最适合的技术路线。在这个技术快速演进的时代，保持架构的灵活性和决策的开放性，比做出一个"完美"选择更加重要。 最适合的部署方案，就是最能支持业务创新和发展的方案。

openGauss概述openGauss是关系型数据库，采用客户端/服务器，单进程多线程架构；支持单机和一主多备部署方式，同时支持备机可读、双机高可用等特性。openGauss有如下基本功能：1、支持标准SQLopenGauss数据库支持标准的SQL（Structured Query Language，结构化查询语言）。SQL标准是一个国际性的标准，定期会进行更新和演进。SQL标准的定义分成核心特性以及可选特性，绝大部分的数据库都没有100%支撑SQL标准。openGauss数据库支持SQL92/SQL99/SQL2003等，同时支持SQL2011大部分的核心特性，另外还支持部分的可选特性。2、支持标准开发接口openGauss数据库提供业界标准的ODBC（Open Database Connectivity，开放式数据库连接）及JDBC（Java Database Connectivity，java数据库连接）接口，保证用户能将业务快速迁移至openGauss。目前支持标准的ODBC3.5及JDBC4.0接口，其中ODBC能够支持CentOS、openEuler、SUSE、Win32、Win64等平台，JDBC无平台差异。3、混合存储引擎支持openGauss数据库支持行存储引擎、列存储引擎和内存存储引擎等。行存分为“inplace update” 和 “append update”两种模式，前者通过单独的回滚段（undo log）来保留元组的前像以解决读写冲突，可以更自然的支持数据更新；后者将更新记录混杂在数据记录中，通过新旧版本的形式来支持数据更新，对于旧版本需要定期做vacuum操作来支持磁盘空间的回收。列存支持数据快速分析，更适合OLAP（Online Analytical Processing，联机分析处理）业务。内存引擎支持实时数据处理，对有极致性能要求的业务提供支撑。4、事务支持事务支持指的就是系统提供事务的能力，openGauss支持事务的原子性、一致性、隔离性和持久性。事务支持及数据一致性保证是绝大多数数据库的基本功能，只有支持了事务，才能满足事务化的应用需求。用户和角色管理是数据库管理系统中的重要功能，用于管理数据库中的用户和角色，以控制对数据库的访问权限。用户是数据库中的实体，用于标识和管理数据库中的各种操作权限和资源使用权限。而角色是一组权限的集合，可以将一组用户分配到同一个角色上，从而简化权限管理和控制。在openGauss数据库中，用户和角色管理可以通过SQL语句或者openGauss控制台来完成。通过创建、修改、删除用户和角色，可以控制用户的身份验证和访问权限。用户 使用数据库系统服务的个体  职责单一，往往附属于某个组织或部门用户可以做什么  使用工具连接数据库  访问数据库对象  执行SQL语句角色 角色是一组用户的集合，按照数据库系统中承担的责任划分具有不同权限的角色；角色用来作 为权限集合的载体。 ⚫ openGauss 提供了一个隐式定义的拥有所有角色的组PUBLIC，所有创建的用户和角色默 认拥有PUBLIC所拥有的权限。 ⚫ 要撤销或重新授予用户和角色对PUBLIC的权限，可通过在GRANT和REVOKE指定关键字 PUBLIC实现。用户与角色⚫ 用户是实体，角色是行为。 ⚫ 用户可被赋予一个或多个角色。⚫ 角色是一种权限集合，不应该具有登录数据库并执行SQL的能力。 ⚫ 对用户权限的管理，可以简化为对角色权限的管理。 ⚫ 在openGauss中，用户和角色使用相同的操作方式与维护方式。实际使用中的选择在OpenGauss中，CREATE USER更常用于以下场景：需要创建实际登录数据库的账号时为应用程序或个人用户创建账户时而CREATE ROLE通常用于：创建权限组（如read_only_role, write_role等）实现权限继承和组合作为模板角色语法CREATE USER name [ [ WITH ] option [ ... ] ] 这里 option 可以是： SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | INHERIT | NOINHERIT | LOGIN | NOLOGIN | REPLICATION | NOREPLICATION | BYPASSRLS | NOBYPASSRLS | CONNECTION LIMIT connlimit | [ ENCRYPTED ] PASSWORD 'password' | PASSWORD NULL | VALID UNTIL 'timestamp' | IN ROLE role_name [, ...] | IN GROUP role_name [, ...] | ROLE role_name [, ...] | ADMIN role_name [, ...] | USER role_name [, ...] | SYSID uid修改角色/用户ALTER USER role_specification [ WITH ] option [ ... ] 其中 option 可以是： SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | INHERIT | NOINHERIT | LOGIN | NOLOGIN | REPLICATION | NOREPLICATION | BYPASSRLS | NOBYPASSRLS | CONNECTION LIMIT connlimit | [ ENCRYPTED ] PASSWORD 'password' | PASSWORD NULL | VALID UNTIL 'timestamp' ALTER USER name RENAME TO new_name ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter { TO | = } { value | DEFAULT } ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter FROM CURRENT ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] RESET configuration_parameter ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] RESET ALL删除角色/用户DROP USER [ IF EXISTS ] name [, ...]查询类操作：  openGauss的用户、角色属性维护在pg_authid系统表中，pg_user、pg_roles视图也可以查询 用户、角色信息。  使用\d命令查看pg_authid表详细信息。  使用select命令查询pg_authid中的相关信息。角色属性角色可以拥有属性，属性确定了角色拥有的特权，并且在登录时与客户端认证系统进行交互。常见的角色属性包括：• 登录特权，只有具有 LOGIN 属性的角色才能连接数据库。具有 LOGIN 角色的用户可以被看作一个“数据库用户”。使用以下语句创建具有登录特权的角色：CREATE ROLE name LOGIN;CREATE USER name;CREATE USER 与 CREATE ROLE 都可以用于创建角色，只不过 CREATE USER 默认包含了 LOGIN 选项，而 CREATE ROLE 没有。• 超级用户，数据的超级用户可以避开所有的权限检查，只验证登录权限。因此，这是一个很危险的特权，使用时需要特别小心；最好在日常的操作中避免使用超级用户。使用以下命令创建一个新的超级用户：CREATE ROLE name SUPERUSER;只有超级用户才能创建其他的超级用户。• 创建数据库，只有明确授权的角色才能够创建数据库（超级用户除外，因为他们可以避开权限检查）。使用以下语句创建一个具有数据库创建特权的角色：CREATE ROLE name CREATEDB;• 创建角色，只有明确授权的角色才能够创建其他角色（超级用户除外，因为他们可以避开权限检查）。使用以下命令创建一个具有角色创建特权的角色：CREATE ROLE name CREATEROLE;具有 CREATEROLE 特权的角色还可以修改或删除其他角色，以及为这些角色授予或者撤销成员角色。但是，针对超级用户的创建、修改、删除，以及它的成员变更，需要超级用户特权；CREATEROLE 特权无法针对超级用户执行这些操作。• 启动复制，只有明确授权的角色才能够启动流复制（超级用户除外，因为他们可以避开权限检查）。用于流复制的角色还需要拥有 LOGIN 特权。使用以下语句创建可以用于流复制的角色：CREATE ROLE name REPLICATION LOGIN;• 密码，只有当用户连接数据库使用的客户端认证方法要求提供密码时，密码属性才有意义。password 和 md5 认证方法需要使用密码。数据库的密码与操作系统的密码相互独立。使用以下语句在创建角色时指定密码：CREATE ROLE name PASSWORD 'string';我们在创建角色时，可以根据需要指定某些属性。例如，以下命令创建一个具有登录特权的角色 tony，并且为它指定了密码以及密码过期时间：CREATE ROLE tony WITH LOGIN PASSWORD 'Pass2019' VALID UNTIL '2020-01-01';-- CREATE USER tony WITH PASSWORD 'Pass2019' VALID UNTIL '2020-01-01';使用该用户连接到 postgres 数据库：[root@centos7 ~]# psql -h 192.168.56.103 -p 5432 -U tony postgresPassword for user tony:psql (14.2)Type "help" for help.postgres=> \cYou are now connected to database "postgres" AS user "tony".psql 命令行工具支持许多选项，-h 表示数据库服务器的地址，-p 表示服务的监听端口，-U表示登录使用的用户名，最后的 postgres 代表要连接的数据库。详细的命令行参数可以使用 psql--help 查看。以下命令创建一个管理角色 admin，它具有创建数据库和创建角色的特权：opengauss=# CREATE ROLE admin CREATEDB CREATEROLE; CREATE ROLE在实践中，最好创建一个拥有 CREATEDB 和 CREATEROLE 特权，但不具有超级用户特权的管理角色，然后使用该角色执行日常的数据库和角色的管理。这种方式可以避免过度使用超级用户可能带来的风险。一个角色被创建之后，可以通过 ALTER ROLE 语句修改它的属性。例如，以下命令可以撤销角色 admin 创建角色的特权：opengauss=# ALTER ROLE admin NOCREATEROLE; ALTER ROLE2.3 对象授权当我们使用新创建的用户（tony）连接数据库（hrdb）之后，执行以下查询语句：hrdb=> SELECT * FROM employees; ERROR: permission denied for table employees以上语句执行错误是因为用户没有相应对象上的访问权限。opengauss使 GRANT 语句进行数据库对象的授权操作。以表为例，基本的授权语法如下：GRANT privilege_list | ALL ON [ TABLE ] table_name TO role_name;其中，privilege_list 权限列表可以是 SELECT、INSERT、UPDATE、DELETE、TRUNCATE等，ALL 表示表上的所有权限。例如，使用 gauss用户连接 hrdb 数据库后执行以下语句：hrdb=# GRANT SELECT, INSERT, UPDATE, DELETE hrdb-# ON employees, departments, jobs hrdb-# TO tony;GRANT该语句将 employees、departments 和 jobs 表上的增删改查权限授予了 tony 用户。此时 tony用户就可以访问这些表中的数据：hrdb=> SELECT first_name, last_name FROM employees;对表进行授权的 GRANT 语句还支持一些其他选项：GRANT privilege_list | ALL ON ALL TABLES IN SCHEMA schema_name TO role_name;ALL TABLES IN SCHEMA 表示某个模式中的所有表，可以方便批量授权操作。例如：hrdb=# GRANT SELECT hrdb-# ON ALL TABLES IN SCHEMA public hrdb-# TO tony;GRANT该语句将 public 模式中所有表的查询权限授予 tony 用户。我们也可以在 GRANT 语句的最后指定一个 WITH GRANT OPTION，意味着被授权的角色可以将该权限授权其他角色。例如：hrdb=# GRANT SELECT, INSERT, UPDATE, DELETE hrdb-# ON employees, departments, jobs hrdb-# TO tony WITH GRANT OPTION;此时，tony 用户不但拥有这些表上的访问权限，还可以将这些权限授予其他角色。除了授权表的访问权限之外，GRANT 语句还支持字段、视图、序列、数据库、函数、过程、模式等对象的授权操作。2.4 撤销授权与授权操作相反的就是撤销权限，opengauss使 REVOKE 语句撤销数据库对象上的权限。同样以表为例，基本的撤销授权语句如下：REVOKE privilege_list | ALL ON TABLE table_name FROM role_name;其中的参数和 GRANT 语句一致。例如：hrdb=# REVOKE SELECT, INSERT, UPDATE, DELETE hrdb-# ON employees, departments, jobs hrdb-# FROM tony;REVOKE该语句撤销了用户 tony 访问 employees、departments 以及 jobs 表的权限。REVOKE 语句也支持对某个模式中的所有对象进行操作：REVOKE privilege_list | ALL ON ALL TABLES IN SCHEMA schema_name FROM role_name;例如以下语句撤销了用户 tony 在 public 模式中所有表上的查询权限：hrdb=# REVOKE SELECT hrdb-# ON ALL TABLES IN SCHEMA public hrdb-# FROM tony;REVOKE与 GRANT 语句对应，REVOKE 语句还支持字段、视图、序列、数据库、函数、过程、模式等对象的撤销授权操作。2.5 角色成员在现实的环境中，管理员通常需要管理大量的用户和对象权限。为了便于权限管理，减少复杂度，可以将用户进行分组，然后以组为单位进行权限的授予和撤销操作。为此，opengauss引入了组（group）角色的概念。具体来说，就是创建一个代表组的角色，然后将该组的成员资格授予其他用户，让其成为该组的成员。首先，使用以下创建一个组角色：CREATE ROLE group_name;按照习惯，组角色通常不具有 LOGIN 特权，也就是不能作为一个用户登录。例如，我们可以先创建一个组 managers：CREATE ROLE managers;然后，使用与对象授权操作相同的 GRANT 和 REVOKE 语句为组添加和删除成员：GRANT group_name TO user_role, ... ; REVOKE group_name FROM user_role, ... ;我们将用户 tony 添加为组 managers 的成员：opengauss=# GRANT managers TO tony; GRANT ROLE最后一行输出显示了成员角色（tony）所属的组（managers）。也可以将一个组添加为其他组的成员，因为组角色和非组角色并没有什么本质区别。opengauss=# GRANT admin TO managers; GRANT ROLE另外，opengauss不允许设置循环的成员关系，也就是两个角色互相为对方的成员。opengauss=# GRANT managers TO admin; ERROR: role "managers" is a member of role "admin"最后，不能将特殊角色 PUBLIC 设置为任何组的成员。组角色中的成员可以通过以下方式使用该组拥有的特权：• 首先，组中的成员可以通过 SET ROLE 命令将自己的角色临时性“变成”该组角色。此时，当前数据库会话拥有该组角色的权限，而不是登录用户的权限；并且会话创建的任何数据库对象归组角色所有，而不是登录用户所有。• 其次，对于具有 INHERIT 属性的角色，将会自动继承它所属的组的全部特权，包括这些组通过继承获得的特权。考虑以下示例：CREATE ROLE user1 LOGIN INHERIT; CREATE ROLE net_admins NOINHERIT; CREATE ROLE sys_admins NOINHERIT; GRANT net_admins TO user1; GRANT sys_admins TO net_admins;使用角色 user1 登录之后，数据库会话将会拥有 user1 自身的特权和 net_admins 所有的特权，因为 user1“继承”了 net_admins 的特权。但是，会话还不具有 sys_admins 所有的特权，因为即使user1 间接地成为了 sys_admins 的成员，通过 net_admins 获得的成员资格具有 NOINHERIT 属性，也就不会自动继承权限。如果执行了以下语句：SET ROLE net_admins;会话将会拥有 net_admins 所有的特权，但是不会拥有 user1 自身的特权，也不会继承sys_admins 所有的特权。如果执行了以下语句：SET ROLE sys_admins;会话将会拥有 sys_admins 所有的特权，但是不会拥有 user1 或者 net_admins 所有的特权。如果想要恢复初始状态的会话特权，可以执行以下任意语句：SET ROLE user1; SET ROLE NONE; RESET ROLE;在 SQL 标准中，用户和角色之间存在明确的差异，用户不会自动继承特权，而角色会继承特权。opengauss可以实现这种行为，只需要为角色设置 INHERIT 属性，而为用户设置NOINHERIT 属性。但是，为了兼容 8.1 之前的版本实现，PostgreSQL 默认为所有的角色都设置了 INHERIT 属性，这样用户总是会继承它所在组的权限。只有数据库对象上的普通权限可以被继承，角色的 LOGIN、SUPERUSER、CREATEDB 以及 CREATEROLE 属性可以被认为是一些特殊的权限，不会被继承。如果想要使用这些权限，必须使用 SET ROLE 命令设置为具有这些属性的角色。基于上面的示例，我们可以为 net_admins 角色指定 CREATEDB 和 CREATEROLE 属性。ALTER ROLE net_admins CREATEDB, CREATEROLE;然后再使用 user1 连接数据库，会话不会自动具有这些特权，而是需要执行以下命令：SET ROLE net_admins;2.6 删除角色删除角色的语句如下：DROP ROLE name;如果删除的是组角色，该组中的成员关系会自动从组中删除，但是这些成员角色自身不会受到任何影响。以下示例删除了角色 admin：opengauss=# drop role admin; DROP ROLE由于角色可以拥有数据库中的对象，也可以拥有访问其他对象的权限，删除角色通常不仅仅只是一个简单的 DROP ROLE 语句。在删除角色之前，需要删除它所拥有的对象，或者将这些对象重新赋予其他的角色；同时还需要撤销授予该角色的权限。

在数字化转型的浪潮中，云部署已成为企业不可或缺的选择。然而，面对众多的部署选项，许多技术决策者常常感到困惑：究竟哪种方式最适合我的业务？本文将深入剖析云部署的三种主流方式，从多个维度进行客观对比，帮助您做出明智决策。  一、公有云：成本与弹性的最优解核心特征：公有云是最典型的云部署模式，由云服务商提供共享的基础设施资源，多个租户通过互联网访问相同的计算、存储和网络资源。适用场景：初创企业和中小型企业流量波动明显的互联网业务开发和测试环境数据备份和灾难恢复优势分析：1. 成本效益：采用按需付费模式，无需前期硬件投资，可将资本支出转为运营支出2. 弹性扩展：可根据业务需求快速调整资源规模，轻松应对流量高峰3. 维护简便：服务商负责底层基础设施的维护和升级4. 全球部署：借助服务商的全球数据中心，快速实现业务国际化布局局限性：数据存储在第三方环境，对数据主权有严格要求的行业需要谨慎评估网络性能受互联网质量影响定制化程度相对有限二、私有云：安全与控制的平衡之道核心特征：私有云为企业提供专属的云环境，可以部署在企业自建的数据中心，也可以由第三方托管，但资源完全隔离。适用场景：金融机构、政府单位等监管严格的行业处理敏感数据的企业需要高度定制化的大型企业有特定合规要求的业务系统优势分析：1. 安全保障：物理隔离确保数据完全掌控在企业手中2. 合规支持：更容易满足行业监管要求3. 性能稳定：不受其他租户影响，资源独享4. 深度定制：可根据业务需求进行全方位定制局限性：初始投资较大，需要专业运维团队扩展速度相对较慢总体拥有成本较高三、混合云：灵活与稳健的完美融合核心特征：混合云结合了公有云和私有云的优势，通过专用网络连接，实现工作负载在两种环境间的无缝迁移。适用场景：业务需求波动大的中大型企业数字化转型过程中的传统企业需要兼顾创新与稳定的组织有特定数据驻留要求的国际化企业优势分析：1. 架构灵活：敏感数据存放在私有云，普通业务部署在公有云2. 成本优化：基础负载使用私有云，峰值负载借助公有云弹性3. 风险分散：避免单一供应商锁定4. 平滑演进：支持从传统架构到云原生的渐进式转型局限性：架构设计复杂，技术要求高需要管理多个环境，运维难度较大网络延迟和带宽成本需要重点考虑四、多云策略：避免依赖与优化选择核心特征：多云策略指同时使用两家及以上云服务商的服务，可能是多个公有云组合，也可能是多个私有云组合。适用场景：追求最高程度业务连续性的企业需要利用不同云服务商特色功能的企业希望增强议价能力的大型组织通过不同云服务商服务不同区域业务的跨国公司优势分析：1. 避免锁定：降低对单一供应商的依赖2. 最佳组合：为不同工作负载选择最合适的云平台3. 提升韧性：单个云服务商故障不影响全局业务4. 成本优化：利用供应商间的竞争获取更优价格局限性：管理复杂度最高需要掌握多种技术栈跨云数据传输成本较高五、四种部署方式的多维对比为了更直观地展示差异，我们从六个关键维度进行对比：  六、如何选择适合的云部署方式？选择云部署方式时，建议从以下几个角度进行考量：1. 业务需求：分析业务的关键性、流量模式和性能要求2. 合规要求：评估行业监管政策和数据主权要求3. 技术能力：评估现有团队的技术水平和运维能力4. 成本预算：综合考虑初始投入和长期运营成本5. 发展计划：考虑未来3-5年的业务发展规划实践建议：从小规模试点开始，逐步验证技术路线建立云治理框架，确保可控性和安全性考虑聘请第三方顾问进行客观评估制定清晰的迁移和回滚方案结语云部署没有"一刀切"的最佳方案，每种方式都有其独特的价值和适用场景。重要的是基于企业的实际需求、技术实力和发展战略，选择最适合的部署模式。随着技术的发展和业务需求的变化，云部署策略也需要持续优化和调整。在云时代，灵活性和适应性比任何时候都更加重要。希望本文能为您在云部署的决策过程中提供有价值的参考。

GDS服务是专门导数用的，非常消耗IO资源，具体的cpu资源消耗的如何？ 占用cpu资源占用大吗，能占用多少核？

1024程序员节大家有什么印象深刻的经历吗？

Libcomm 通信库cid:link_4producer 线程cid:link_0通信流cid:link_5TCP代理通信库cid:link_6CN多流cid:link_7集群通信常见问题cid:link_1数据收发过程中报错 cid:link_8使用通信中的视图进行分析cid:link_2增量备份核心设计cid:link_3差分增量备份cid:link_9Checkpoint 操作cid:link_10CBM文件的命名格式cid:link_11Roach的集群级备份cid:link_12流程分析cid:link_13日志回收https://bbs.huaweicloud.com/forum/thread-02107197297724506124-1-1.html

日志是查看代码运行状态和错误定位的重要文件，Roach内核的回收日志只能保证一个日志回收点：$GAUSSLOG/roach/。Roach日志的管理可分为三类： agent文件夹保存了内核侧生成的日志； controller文件夹保存了python侧的调度信息； frame文件夹保存了双集群容灾过程中python侧代码生成的日志。缺省情况下，内核日志仅记录警告及以上级别的消息。Roach工具支持的日志级别，默认只有ERROR和Warning级别日志。执行命令可开启INFO级别日志，--logging –logging-level INFO 如果备份或恢复操作失败，可查看控制台中显示的错误汇总，识别发生错误的主机。 系统日志 Linux记录系统事件至系统日志中。Roach工具将FATAL及ERROR消息记入相同的系统日志文件。例如，在运行SUSE Linux操作系统的设备上，Roach写日志到/var/log/messages文件。 安全日志 用户可以保存所有活动信息到文件中。安全日志文件包括时间戳，以及备份，恢复和生成文件的详细信息。安全日志文件的文件名称格式如下：roach-agentsecurity-YYYY-MM-DD_HHMMSS.log。 控制器日志 控制器日志为python脚本运行日志，用户可以保存控制器日志信息到文件中。 控制器日志文件的格式如下：roach-controller-YYYY-MMDD_HHMMSS.log。例如：roach-controller-2015-12-15_203415.log 

根据GaussDB(DWS)数据库的功能结构，全量备份按照以下顺序备份所需要的文件： 数据库相关的配置文件。 行存全部数据：GaussDB(DWS) A数据库支持行存。 xlog日志文件：Roach支持在线业务的备份，则通过备份xlog日志文件可在恢复时将备份期间的业务Redo，保证数据一致性。 列存全部数据： GaussDB(DWS) A数据库支持列存。 备份的数据按照每个节点为单位进行备份，所以每个节点都只存储当前节点的备份。结合Roach工具备份调度流图和日志信息分析如下： 整个备份流程的上层代码为python代码，即GaussRoach.py，master进程的创建和agent进程的拉起都是由python侧完成的。备份的配置和参数部分检查过程同样是由python侧代码完成。各个节点agent进程被拉起之后，C侧代码进行具体的业务操作。C侧代码运行起来之后，可以通过ps ux到gs_roach进程查看进程状态。备份的数据会进行压缩后写入到rch文件后存储到备份路径下的实例文件夹下，且每个rch文件大小是4GB； 存放路径：[存储路径]/roach/backupkey/hostname/，其中存储路径为备份命令中指定的--media-destination的值，backupkey为当前备份开始的时间作为标识某个特定的备份集，hostname为当前节点的hostname。

Roach的集群级备份采用的是物理备份，即通过物理文件拷贝的方式对数据库进行备份，通过备份的数据文件及日志等文件，数据库可以进行完全恢复。全量备份则是将当前时间点数据库中所有的数据进行备份。当然，全备份可以备份整块硬盘、整个分区或某个具体的目录。全备份的好处是数据恢复方便，因为所有的数据都在同一个备份中，所以只要恢复全备份，所有的数据都会被恢复。 其优点是：物理备份速度快，通过合理规划，可以低成本进行备份和恢复； 其缺点是：相较于增量备份备份时间较长。Roach备份采用生产者-消费者模式，下图展现了备份流程各个线程及IO交互图。exec线程作为生产者，同时为减轻exec线程的压力，增加并行的reader线程读取小文件；sender线程作为消费者；中间则是通过一个256MB（可设置）的大buffer衔接。GaussDB(DWS)内核的备份组件为GaussRoach.py和gs_roach，需在集群内拉起备份任务。GaussRoach.py：Roach单集群全量备份入口为GaussRoach.py。每次命令行输入“python GaussRoach.py –t backup…”后，roach的python语言模式就开始运行。任意节点均可作为主节点拉起GaussRoach.py，然后每个节点都启动gs_roach进程负责本节点备份，各节点并行备份，节点内各DN并行备份。   

CBM 文件保存在data 目录的pg_cbm 文件夹下，命名方式为：pg_xlog_seqnum_startlsn_endlsn.cbm。seqnum文件序号表示这是第几个cbm文件，当一个cbm文件的大小超过100M时，将会切换到下一个cbm文件，并将seqnum加1。 startlsn为本cbm文件内容对应xlog记录的起始lsn； endlsn为本cbm文件切换时最后一次解析的截止lsn，若一个cbm文件还没有切换，那么endlsn为0。pg_cbm_tracked_location 说明：用于查询cbm已经解析到的lsn位置 入参：无 返回值：cbm已经解析到的lsn位置 b. pg_cbm_get_merged_file 说明：用于将指定lsn范围之内的cbm文件合并成一个cbm文件 入参：startlsn，指定的起始lsn；endlsn，指定的结束lsn 返回值：合并完的cbm文件名 c. pg_cbm_get_changed_block 说明：用于将指定lsn范围之内的cbm文件合并一个表，并返回表的各行记录 入参：startlsn，指定的起始lsn；endlsn，指定的结束lsn 返回值：合并完的表的记录，表的结构如下

当系统运行时间较长的时候，由于操作较多，日志文件的数量也较多。如果每次利用日志进行恢复操作都会耗费大量的时间，为了节约时间同时减少不必要的恢复操作，引入了checkpoint的概念。checkpoint表示在此操作之前，相关数据已经被保存到永久存储中，即使系统故障，这部分数据也不会丢失，因此恢复的时候只要从checkpoint操作之后根据日志执行恢复操作就可以了。checkpoint本身也是一条xlog记录，该记录包含了redo点的位置，因此，每次恢复数据时，先从xloh记录里找到最近的一次checkpoint记录，并根据该记录找到相应的redo点位置，这就是执行本次恢复的起始点位置。checkpoint操作记录了redo点的位置。基于上述功能，由于数据的所有变化都被记录在了xlog中，GaussDB(DWS)数据库内核通过增加常驻的CBM writer线程，持续不断地对新增的xlog进行解析，识别并记录哪些数据数据页面被修改。进程启动时即开启CBM writer功能 在startup线程刚启动时，其根据已经解析出来的CBM文件，来决定CBM writer开始解析的起始LSN位置。每次执行到checkpoint末尾时，会设置CBM writer线程的latch。CBM writer线程等待latch被设置，然后进行一轮日志解析。 通过动态reload GUC参数，开启CBM writer功能 由于是动态开启的CBM writer功能，因此startup线程没有初始化CBM解析的起始位置。打开enable_cbm_writer开关的同时，会将CBM强制初始化的标志置为true。当CBM writer线程启动之后，其第一次解析中，会强制初始化获得解析的起始lsn。

如果一次全量备份后的多次增量备份，指定的prior-backup-key均为上一次备份（可能是全量备份也可能增量备份）的backup-key，即此次备份是基于上一次备份集来进行的，那么这些增量备份就是差分增量备份，差分增量备份均是基于最近一次备份进行的。增量备份只需要备份上一备份节点到当前时间发生变化的数据文件，为了实现备份数据的完整性与一致性，正确识别并备份增量数据文件是至关重要的，作为增量备份的核心GaussDB(DWS)数据库内核的事务日志功能与cbm设计可以帮助Roach工具快速准确识别增量期间数据文件的变换信息，为快速准确完成增量备份提供了有力保障。为了保证数据的一致性和完整性，在对数据进行相关操作之前都会将具体的操作记录下来，持久化到可靠存储中，然后再进行具体的数据操作，这就是所谓的WAL（Write Ahead Logging），记录的相关操作称为XLOG日志，每一条日志记录都由LSN进行唯一标识。这样做的好处是事务的记录被提前记录并保存起来，在因一些外部原因（比如断电、操作系统失败等）导致操作失败后，我们可以通过保存的事务日志将这些操作重新执行一遍，保证数据不会丢失。

增量备份指备份基于上一个备份集到当前阶段的数据变化文件，相比于全量备份所用的时间更少，能够节约大量的空间资源，因此一直是客户的常规备份手段。为了实现数据的完整性与一致性，正确识别并备份增量数据文件是至关重要的，Gauss(DWS)数据库内核的事务日志功能与CBM设计可以帮助Roach工具快速准确识别增量期间数据文件的变换信息，从而快速实现增量备份的任务。GaussDB(DWS)数仓的备份恢复工具Roach支持集群级增量备份。全量备份会将源数据完整备份，而增量备份仅将上次备份后所作的更改进行备份，这里的上次备份可以使全量备份，也可以是全量备份后的增量备份。需要注意的是，增量备份的基础始终是全量备份，如果一次全量备份之后进行了全量恢复，则不能再基于该全量备份进行增量备份，必须重新进行全量备份然后基于新的全量备份进行增量备份。 增量备份分为两种：累积增量备份和差分增量备份。如果一次全量备份后的多次增量备份，指定的prior-backup-key始终为全量备份的backup-key，即所有的增量备份都是基于全量备份来进行的，那么这些增量备份就是累积增量备份，累积增量备份均是基于最近一次全量备份进行的。

组合使用pgxc_stat_activity 、 pgxc_thread_wait_status 、pgxc_comm_send_stream、pgxc_comm_recv_stream视图定位问题 在pgxc_stat_activity 视图中找到问题查询的query_id; 根据query_id查询pgxc_thread_wait_status 视图，看到 CN 在等DN4的数据，而DN4在与DN42建连;查询pgxc_comm_send_stream看到DN4发起的与DN2的逻辑连接中有一个处于READY半连接状态；查询pgxc_comm_recv_stream看到DN2已经接受了DN4发起的4个逻辑连接，问题出在DN4逻辑连接应答上。DN间接收数据分两个动作 LibcommRecvPoll，等待数据到达； LibcommRecv，数据到达后接收数据。 Poll Time：等待数据到达所花费的时间； Send time：发送数据并接收对端quota所花费的时间。在GaussDB(DWS)通信运维中，很多情况是由于一些参数配置的不合理导致集群效率低、资源过载、连接异常等问题。对于通信库和操作系统两方面都提供了大量可供用户自定义的参数、视图、脚本，熟练掌握一些重要工具有助于快速定位现网通信故障问题。 

CN 连接DN报错, 主要关注后面的detail信息 Already too many client：DN线程数超过max_connections上限； Connection timed out：TCP建连超时，网络不通或者网络质量差； Connection refused：TCP建连被拒绝，防火墙配置或者端口号错误； timeout expired：连接已经建立，但连接信息同步时对端响应超时。 数据收发过程中报错 cancel/terminate日志：外部信号中止查询； reset by peer/broken pipe：连接对端线程主动关闭连接； Stream closed by remote：对端关闭连接或发生重启，需查看对端日志； Peer address changed：对端DN存在主备切换。 DN 间通信性能差 pv_total_memory_detail中通信内存过大：Libcomm通信库降级运行； gsar监控有严重丢包重传：网络质量差，丢包过多导致连接断开； top查看CPU高或者ksoftirq进程CPU高：排查异常CPU占用。