备份与恢复

1）DB on QFusion 有哪些功能；2）日常运维命令；3）高可用架构；4）备份；5）常见问题

备份

数据备份是保护数据安全的重要手段之一，为了更好的保护数据安全，openGauss数据库支持三种备份恢复类型，以及多种备份恢复方案，备份和恢复过程中提供数据的可靠性保障机制。 备份与恢复类型可分为逻辑备份与恢复、物理备份与恢复、闪回恢复。

• 逻辑备份与恢复：通过逻辑导出对数据进行备份，逻辑备份只能基于备份时刻进行数据转储，所以恢复时也只能恢复到备份时保存的数据。对于故障点和备份点之间的数据，逻辑备份无能为力，逻辑备份适合备份那些很少变化的数据，当这些数据因误操作被损坏时，可以通过逻辑备份进行快速恢复。如果通过逻辑备份进行全库恢复，通常需要重建数据库，导入备份数据来完成，对于可用性要求很高的数据库，这种恢复时间太长，通常不被采用。由于逻辑备份具有平台无关性，所以更为常见的是，逻辑备份被作为一个数据迁移及移动的主要手段。

• 物理备份与恢复：通过物理文件拷贝的方式对数据库进行备份，以磁盘块为基本单位将数据从主机复制到备机。通过备份的数据文件及归档日志等文件，数据库可以进行完全恢复。物理备份速度快，一般被用作对数据进行备份和恢复，用于全量备份的场景。通过合理规划，可以低成本进行备份与恢复。

• 闪回恢复：利用回收站的闪回恢复删除的表。数据库的回收站功能类似于windows系统的回收站，将删除的表信息保存到回收站中。利用MVCC机制闪回恢复到指定时间点或者CSN点。



当需要进行备份恢复操作时，主要从以下四个方面考虑数据备份方案。

备份对业务的影响在可接受范围。

数据库恢复效率。

为尽量减小数据库故障的影响，要使恢复时间减到最少，从而使恢复的效率达到最高。

数据可恢复程度。

当数据库失效后，要尽量减少数据损失。

数据库恢复成本。

在现网选择备份策略时参考的因素比较多，如备份对象、数据大小、网络配置等，表2列出了可用的备份策略和每个备份策略的适用场景。

配置文件的备份与恢复

逻辑备份与恢复

背景信息

gs_dump、gs_dumpall 和 gs_restore 是 GaussDB 数据库的命令行工具，用于数据库的备份和恢复操作。它们与 PostgreSQL 的 pg_dump、pg_dumpall 和 pg_restore 功能类似，但专为 GaussDB 优化。

• gs_dump：用于导出单个数据库的 SQL 文件或自定义格式备份文件。
• gs_dumpall：用于导出所有数据库及全局对象（如角色、表空间）。
• gs_restore：用于从备份文件中恢复数据库，支持自定义格式文件的还原。

---

语法结构

1. gs_dump

用途：单个数据库的备份。
基本语法：

gs_dump [选项] 数据库名 > 输出文件

常见选项：

• --format=FMT (-F FMT)：指定输出格式（p 纯文本 SQL，c 自定义格式，d 目录格式，t tar 格式）。
• --file=FILENAME (-f FILENAME)：指定输出文件名。
• --schema=SCHEMA (-n SCHEMA)：仅导出指定模式的对象。
• --table=TABLE (-t TABLE)：仅导出指定表的数据。

2. gs_dumpall

用途：所有数据库及全局对象的备份。
基本语法：

gs_dumpall [选项] > 输出文件

常见选项：

• --globals-only：仅导出全局对象（角色、表空间）。
• --roles-only：仅导出角色。
• --no-owner：不包含对象的所有权信息。
• --no-privileges：不包含访问权限信息。

3. gs_restore

用途：从备份文件中恢复数据库。
基本语法：

gs_restore [选项] -d 数据库名 输入文件

常见选项：

• --format=FMT (-F FMT)：指定输入文件格式（c 自定义，d 目录，t tar）。
• --dbname=DBNAME (-d DBNAME)：指定目标数据库。
• --schema=SCHEMA (-n SCHEMA)：仅恢复指定模式。
• --table=TABLE (-t TABLE)：仅恢复指定表。
• --clean：恢复前删除现有对象。
• --if-exists：删除对象时使用 IF EXISTS 避免报错。

---

参数说明

参数类型	描述
数据库名	指定备份或恢复的目标数据库名称（gs_dump 和 gs_restore 需提供）。
输出/输入文件	gs_dump 和 gs_dumpall 的输出文件路径；gs_restore 的输入备份文件路径。
格式（–format）	控制备份文件格式（p、c、d、t），不同格式影响存储效率和恢复方式。
模式（–schema）	限制操作范围到特定数据库模式（Schema）。
表（–table）	限制操作范围到特定表（Table）。
全局对象选项	gs_dumpall 中的 --globals-only、--roles-only 等，控制导出内容范围。

---

总结

• gs_dump：单库备份工具，灵活控制导出范围和格式。
• gs_dumpall：全库备份工具，适合迁移或全局对象管理。
• gs_restore：恢复工具，支持按需恢复和清理旧数据。

以上信息基于图片中提供的 GaussDB 工具说明，可直接用于实际操作指导。

详细内容：逻辑备份详细

物理备份

1. gs_backup

背景信息

gs_backup 是用于数据库备份的工具，通常与 GaussDB 等数据库系统关联，支持创建完整备份以便后续恢复。

前提条件

• 安装并配置支持 gs_backup 的数据库系统。
• 用户需具备执行备份操作的权限。

语法结构

gs_backup [OPTIONS]...

参数说明

• OPTIONS：
  • 备份模式（全量/增量）。
  • 备份目标路径（如 -D /backup_path）。
  • 压缩选项（如 --compress 启用压缩）。

---

2. gs_basebackup

背景信息

gs_basebackup 是 PostgreSQL 的文件系统级备份工具（GaussDB 版本），用于创建数据库集群的物理备份。

前提条件

• PostgreSQL 或兼容服务器正在运行。
• 用户需拥有 REPLICATION 权限。

语法结构

gs_basebackup [OPTION]...

参数说明

• OPTION：
  • -D：指定备份目录（如 -D /backup_dir）。
  • -h：指定主机地址（如 -h 192.168.1.100）。
  • -p：指定端口（如 -p 5432）。
  • -U：指定用户名（如 -U replicator）。

---

3. PITR恢复

背景信息

PITR（Point-In-Time Recovery）是 PostgreSQL 的时间点恢复机制，允许数据库恢复到任意历史时间点。

前提条件

• 配置 WAL（Write-Ahead Log）归档。
• 存在完整的基备份和归档的 WAL 文件。

语法结构

通过编辑 recovery.conf 文件实现，例如：

restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2023-10-01 12:00:00'

参数说明

• restore_command：定义如何恢复 WAL 文件（如从归档路径复制）。
• recovery_target_time：指定恢复到的时间点。

---

4. gs_probackup

背景信息

gs_probackup 是企业级备份工具，支持并行备份、增量备份、备份验证等高级功能。

前提条件

• 安装 gs_probackup 工具。
• 用户需具备数据库管理权限。

语法结构

gs_probackup [COMMAND] [OPTIONS]...

参数说明

• COMMAND：
  • backup：创建备份（如 gs_probackup backup -B /backup_dir --instance=inst1）。
  • restore：恢复备份（如 gs_probackup restore -B /backup_dir --instance=inst1 -D /restore_dir）。
  • validate：验证备份完整性。
• OPTIONS：
  • -B：指定备份目录。
  • --instance：指定实例名称。
  • --mode：指定备份模式（如 full 全量备份）。

---

总结

• gs_backup 和 gs_basebackup：用于创建数据库备份。
• PITR恢复：基于 WAL 的时间点恢复。
• gs_probackup：企业级工具，支持复杂备份策略。
  根据数据库类型和需求选择合适工具。
  详细内容：物理备份

闪回

闪回查询（Flashback Query）

背景信息

闪回查询是一种数据库功能，允许用户查询过去某个时间点的数据状态。在 OpenGauss 数据库中，通过使用 AS OF 子句实现闪回查询。这一特性对于数据恢复、审计和分析历史数据非常有用。

前提条件

• 确保 OpenGauss 数据库已正确安装并运行。
• 需要开启事务日志记录功能，以支持闪回查询。
• 用户需具备相应的权限来执行查询操作。

语法结构

SELECT * FROM table_name AS OF TIMESTAMP timestamp_expression;

参数说明

• table_name：需要进行闪回查询的表名。
• timestamp_expression：指定的时间戳表达式，表示要查询的历史时间点。

使用示例

假设有一个名为 employees 的表，我们想要查询 2023-10-01 12:00:00 这个时间点的数据：

SELECT * FROM employees AS OF TIMESTAMP '2023-10-01 12:00:00';

---

闪回表（Flashback Table）

背景信息

闪回表功能允许用户将一个表的状态恢复到过去的某个时间点。OpenGauss 提供了 FLASHBACK TABLE 语句来实现这一功能，这对于误操作后的数据恢复特别有用。

前提条件

• 确保 OpenGauss 数据库已正确安装并运行。
• 需要开启事务日志记录功能，以支持闪回操作。
• 用户需具备相应的权限来执行闪回操作。

语法结构

FLASHBACK TABLE table_name TO TIMESTAMP timestamp_expression;

参数说明

• table_name：需要进行闪回操作的表名。
• timestamp_expression：指定的时间戳表达式，表示要恢复到的历史时间点。

使用示例

假设有一个名为 orders 的表，我们想要将其状态恢复到 2023-10-01 14:00:00 这个时间点：

FLASHBACK TABLE orders TO TIMESTAMP '2023-10-01 14:00:00';

---

闪回 DROP/TRUNCATE 操作

背景信息

当表被 DROP 或 TRUNCATE 后，可以通过闪回功能恢复这些操作。OpenGauss 提供了 FLASHBACK DROP 和 FLASHBACK TRUNCATE 功能来实现这一点。

前提条件

• 确保 OpenGauss 数据库已正确安装并运行。
• 需要开启事务日志记录功能，以支持闪回操作。
• 用户需具备相应的权限来执行闪回操作。

语法结构

闪回 DROP 操作

FLASHBACK DROP TABLE table_name;

闪回 TRUNCATE 操作

FLASHBACK TRUNCATE TABLE table_name;

参数说明

• table_name：需要进行闪回操作的表名。

使用示例

假设有一个名为 products 的表被误删除或清空，我们可以使用以下命令恢复：

恢复被删除的表

FLASHBACK DROP TABLE products;

恢复被清空的表

FLASHBACK TRUNCATE TABLE products;

---

总结

• 闪回查询：用于查询过去某个时间点的数据状态。
• 闪回表：用于将表的状态恢复到过去的某个时间点。
• 闪回 DROP/TRUNCATE：用于恢复被删除或清空的表。

以上功能在 OpenGauss 中提供了强大的数据恢复和历史数据查询能力，适用于多种场景下的数据管理和维护需求。

日常维护

日常运维命令

1. 检查操作系统参数

确保操作系统配置符合数据库运行的最佳实践。

命令示例

# 查看系统内核参数
sysctl -a | grep -E "fs.file-max|kernel.shmmax|vm.swappiness"

# 查看文件描述符限制
ulimit -n

# 查看磁盘空间使用情况
df -h

# 查看内存使用情况
free -m

# 查看CPU使用情况
top -b -n 1 | head -n 20

关键参数说明

• fs.file-max：最大打开文件数。
• kernel.shmmax：共享内存段的最大值。
• vm.swappiness：控制虚拟内存的使用策略。
• ulimit -n：当前进程允许打开的最大文件描述符数。

---

2. 检查openGauss健康状态

监控数据库服务的状态和基本健康指标。

命令示例

# 检查数据库服务是否正常运行
pg_ctl status -D /data/opengauss/data

# 查看数据库连接状态
psql -U gaussdb -d postgres -c "SELECT * FROM pg_stat_activity;"

# 检查监听端口
netstat -anp | grep 5432

# 检查数据库日志文件
tail -f /data/opengauss/log/postgresql.log

关键参数说明

• pg_ctl status：检查指定数据目录下的数据库实例状态。
• pg_stat_activity：显示所有活动会话的信息，包括查询、等待锁等。
• netstat -anp：查看网络连接状态及对应的进程信息。

---

3. 检查数据库性能

评估数据库的性能指标，识别潜在瓶颈。

命令示例

# 查看慢查询日志
cat /data/opengauss/log/slow_query.log

# 使用pgBadger分析慢查询
pgbadger /data/opengauss/log/postgresql.log -o slow_queries.html

# 监控数据库性能指标
psql -U gaussdb -d postgres -c "SELECT * FROM pg_stat_database;"

# 分析表的统计信息
psql -U gaussdb -d your_db -c "ANALYZE VERBOSE your_table;"

关键参数说明

• pg_stat_database：显示每个数据库的统计信息，如事务数、块读取量等。
• ANALYZE：更新表的统计信息，帮助优化器生成更优的执行计划。

---

4. 检查和清理日志

定期检查和清理日志文件，避免磁盘空间不足。

命令示例

# 查看日志文件大小
du -sh /data/opengauss/log/*

# 清理旧的日志文件（保留最近7天）
find /data/opengauss/log/ -type f -name "*.log" -mtime +7 -exec rm -f {} \;

# 压缩旧日志文件
gzip /data/opengauss/log/*.log

# 配置日志轮转（在postgresql.conf中）
log_rotation_age = 1d
log_rotation_size = 10MB

关键参数说明

• find：查找并删除超过7天的日志文件。
• gzip：压缩日志文件以节省存储空间。
• log_rotation_age 和 log_rotation_size：设置日志轮转的时间和大小阈值。

---

总结

日常运维命令涵盖了从操作系统层面到数据库层面的多个方面，通过定期执行这些命令，可以及时发现和解决潜在问题，保障数据库系统的稳定运行。结合自动化脚本和监控工具，可以进一步提高运维效率和响应速度。

常见故障定位手段

OpenGauss 常见故障定位手段

在 OpenGauss 数据库的运维过程中，故障定位是保障系统稳定性和高可用性的关键环节。以下从 操作系统故障、网络故障、磁盘故障 和 数据库故障 四个层面，系统化地总结了常见的故障定位手段及解决方法。

---

一、操作系统故障定位手段

当节点状态异常（如所有实例显示为 Unknown）时，需优先排查操作系统问题。

1. 基础检查

   • 登录状态检测：
     使用 ping 检查网络连通性，若无法响应，可能为网络中断、机器宕机或重启中。

     • 若 ping 成功但 SSH 登录卡顿，可能因 CPU/IO 资源过载 导致系统无响应。
     • 若 SSH 登录后无法执行命令，需检查系统日志（/var/log/messages 或 dmesg）是否存在内核 panic 或资源耗尽问题。

   • 系统基本信息：

     who           # 查看当前登录用户
     cat /etc/openEuler-release  # 检查操作系统版本
     uname -a      # 查看内核信息
     

2. 资源监控

   • CPU 使用率：

     top -H        # 查看线程级 CPU 占用
     

     • 若某进程 CPU 占用过高，使用 gdb 或 gstack 分析堆栈，确认是否死循环。

   • 内存与 IO：

     iostat -x 1 3 # 监控磁盘 IO 饱和度
     vmstat 1 3    # 观察内存消耗及交换分区使用情况
     

3. 参数与日志

   • 系统参数：

     sysctl -a     # 查看内核参数
     cat /proc/cpuinfo && cat /proc/meminfo  # 获取 CPU/内存硬件信息
     

   • 日志分析：

     dmesg         # 查看内核日志
     tail -n 100 /var/log/messages  # 检查系统异常记录
     

   • Watchdog 机制：
     若系统因 watchdog 超时（默认 60s）复位，需检查内核配置或硬件稳定性。

---

二、网络故障定位手段

网络问题是 OpenGauss 集群故障的主要诱因之一，需结合系统工具与数据库日志定位根源。

1. 端口冲突与防火墙

   • 端口占用检查：

     netstat -anop | grep <端口号>  # 如 5432
     

     • 若端口被占用，需终止冲突进程或调整数据库监听端口。

   • 防火墙配置：

     systemctl status firewalld  # 检查防火墙状态
     systemctl stop firewalld    # 临时关闭防火墙
     

2. 网络连通性验证

   • 基础测试：

     ping <目标IP>              # 检查网络层连通性
     telnet <目标IP> <端口>     # 检查端口可达性
     

   • 网卡状态：

     ifconfig <网卡名>          # 查看丢包（dropped）和错误（errors）计数
     

     • 若丢包率高，可能因网卡驱动异常或硬件故障。

3. 数据库状态异常

   • 主备切换问题：

     • 使用 gs_om -t status --detail 检查主备状态。
     • 若主备连接失败，需排查网络延迟或防火墙规则。

   • 连接中断错误：

     • 日志中出现 Connection reset by peer 或 Connection timed out，需结合 gs_check 检查网络配置，或联系网络团队分析链路质量。

---

三、磁盘故障定位手段

磁盘问题可能导致数据库服务异常或数据损坏，需重点关注空间、坏块及挂载状态。

1. 空间与挂载

   • 空间不足：

     df -h                        # 检查磁盘使用率
     

     • 若空间达 100%，清理日志或扩展存储（如 /data 目录）。

   • 挂载异常：

     • 若 ls -l <挂载点> 显示权限异常，可能因磁盘未正确挂载或文件系统损坏。

2. 坏块检测

   • 坏块扫描：

     badblocks /dev/sdX -s -v     # 检查磁盘坏块（X 为磁盘标识符）
     

     • 若发现坏块，需更换硬盘或修复文件系统。

3. 文件系统损坏

   • 日志特征：
     • 数据库日志中出现 data path disc writable test failed，可能因磁盘未挂载或坏块导致文件系统保护性锁定。

---

四、数据库故障定位手段

数据库自身的日志、视图及 core 文件是定位问题的核心依据。

1. 日志分析

   • 关键日志路径：
     • 数据库日志：/data/opengauss/log/postgresql-YYYY-MM-DD.log
     • Panic 日志：/data/opengauss/log/panic-*.log
   • 典型错误示例：
     • could not bind socket：端口冲突。
     • No space left on device：磁盘空间不足。
     • invalid page header：数据文件损坏。

2. 视图查询

   • 会话状态：

     SELECT * FROM pg_stat_activity;  -- 查看活动会话
     

   • 锁与等待事件：

     SELECT * FROM pg_locks;          -- 锁冲突分析
     SELECT * FROM pg_thread_wait_status;  -- 线程等待事件
     

3. Core 文件处理

   • 生成路径配置：

     echo "/data/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
     

   • 分析方法：
     • 使用 gdb 或 gstack 解析 core 文件，定位崩溃原因。
     • 频繁生成 core 文件时，需检查内存泄漏或代码缺陷。

4. 工具辅助

   • gs_check：
     • 执行 gs_check -D /data/opengauss/data 检查集群健康状态。
   • gs_om：
     • 使用 gs_om -t status --detail 查看实例状态及主备关系。

---

五、总结与预防建议

1. 定期监控

   • 通过自动化脚本监控 CPU、内存、磁盘及网络状态，设置阈值告警。

2. 备份与恢复

   • 定期备份日志、配置文件及核心数据，确保灾难恢复能力。

3. 参数优化

   • 根据业务负载调整内核参数（如 net.ipv4.tcp_retries1）和数据库配置（如 shared_buffers）。

4. 文档与演练

   • 记录历史故障及解决方案，定期进行故障切换演练，提升团队应急响应能力。