开源项目OpenIM单机部署生产环境异常处理及数据恢复

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介: 在生产环境中,通常会采用集群部署来保证组件和服务的高可用性。然而,在资源有限的情况下,一些开发者可能会选择在生产环境中进行单机部署(使用源码部署或docker容器)。本文将介绍在单机部署环境下如何进行数据备份、异常恢复,以及潜在的风险。一、mongo定时数据备份​OpenIM核心数据存储在MongoDB中,因此备份MongoDB数据就能恢复大部分数据。在容器启动之前,设置mongo数据备份目录和定时任务。数据备份​OpenIM服务的核心数据存储在MongoDB中,因此备份MongoDB数据就能恢复大部分数据。以下是备份的步骤:修改备份目录.env文件中修改MONGO_BACK

在生产环境中,通常会采用集群部署来保证组件和服务的高可用性。然而,在资源有限的情况下,一些开发者可能会选择在生产环境中进行单机部署(使用源码部署或docker容器)。本文将介绍在单机部署环境下如何进行数据备份、异常恢复,以及潜在的风险。

一、mongo定时数据备份​
OpenIM核心数据存储在MongoDB中,因此备份MongoDB数据就能恢复大部分数据。在容器启动之前,设置mongo数据备份目录和定时任务。

数据备份​
OpenIM服务的核心数据存储在MongoDB中,因此备份MongoDB数据就能恢复大部分数据。以下是备份的步骤:

修改备份目录
.env文件中修改MONGO_BACKUP_DIR的路径,默认值为components/backup/mongo/。建议将备份目录设置为与components目录不同的磁盘路径,以避免同一磁盘故障导致原始数据和备份数据同时丢失。
定时备份配置
配置Linux系统的定时备份任务,执行以下命令编辑crontab:
crontab -e
添加如下定时任务,表示每天凌晨2点执行备份,并保存最新的2个备份文件。如果需要其他定时规则,请调整cron表达式:0 2 * docker exec mongo mongodump --uri="mongodb://openIM:openIM123@localhost:27017/openim_v3" --out="/data/backup/(expr(date +\%s) / 86400 \% 2)"
使用crontab -l命令可以查看当前定时任务是否设置成功。
二、组件异常停止处理​
如果 mongo、redis、kafka、etcd 等组件异常停止,首先尝试重启所有组件和 OpenIM 服务。
如果由于数据问题(如磁盘故障、磁盘满等)导致服务启动失败,则先停止所有组件和 OpenIM 服务。
如果 redis 启动失败,删除 components/redis/ 目录。
如果 kafka 启动失败,删除 components/kafka/ 目录。
如果 mongo 启动失败
删除 components/redis/components/mongodb/components/kafka/目录
恢复备份数据 docker exec -it mongo mongorestore --uri="mongodb://openIM:openIM123@localhost:27017/openim_v3" /data/backup/your_backup_name/openim_v3
your_backup_name 为0 或者1, 选择时间较新的那个目录
如果 etcd 启动失败,删除 components/etcd/ 目录。
3.在进行上述操作后,重启所有组件和 OpenIM 服务。

三、潜在风险​
单机部署风险
如果机器故障导致原始数据磁盘和备份磁盘都无法访问,则无法直接恢复数据。此时,可能需要通过运营商的快照服务来恢复数据。
备份目录建议
为防止由于单一磁盘故障导致的数据丢失,建议将 mongo 的备份目录 MONGO_BACKUP_DIR 设置为与 components 目录分开的磁盘。
数据恢复风险
恢复 MongoDB 数据时,备份时间之后的数据将会丢失。因此,备份频率过快可能会对 MongoDB 的性能造成较大的影响。
Redis 数据删除的影响
如果删除 Redis 中的数据,可能会导致 消息未读数不正确。v2-15cd0728082be9802c31661c28981c15_1440w.jpg

github: 仓库地址

developer: 开发文档

OpenIM
+关注
目录
打赏
0
10
10
1
37
分享
相关文章
分布式链路监控系统问题之kywalking在后期维护过程中可能会遇到中间件版本升级的问题如何解决
分布式链路监控系统问题之kywalking在后期维护过程中可能会遇到中间件版本升级的问题如何解决
|
8月前
|
项目环境测试问题之单机调度会导致项目环境大部分的机器被闲置如何解决
项目环境测试问题之单机调度会导致项目环境大部分的机器被闲置如何解决
|
9月前
|
开发与运维特性问题之jmap命令功能如何解决
开发与运维特性问题之jmap命令功能如何解决
84 0
AutoMQ 自动化持续测试平台技术内幕
Marathon 是一个针对流系统 AutoMQ 的自动化持续测试平台,旨在在模拟生产环境和各种故障场景中验证 SLA 的可靠性。设计原则包括易拓展、可观测和低成本。平台采用分布式架构,Controller 负责资源管理和任务编排,动态调整 Worker 数量和配置,而 Worker 是无状态的,用于生成负载和上报数据。系统基于 K8S,利用服务发现、事件总线和 Spot 实例降低成本并提高弹性。测试场景以代码形式描述,支持不同流量模型和断言,提供丰富的可观测性和告警功能。未来,Marathon 有望泛化为适用于各种分布式系统的测试平台。
75 0
AutoMQ 自动化持续测试平台技术内幕
聊聊深入挖掘业务需求,可0-1设计高可用、高并发、高伸缩的分布式项目架构,环境搭建、自动化部署、服务器环境线上排查、性能评估
聊聊深入挖掘业务需求,可0-1设计高可用、高并发、高伸缩的分布式项目架构,环境搭建、自动化部署、服务器环境线上排查、性能评估
129 0
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 3【上传gitlab后自动部署到服务器】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 3【上传gitlab后自动部署到服务器】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 3【上传gitlab后自动部署到服务器】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 1 【部署到服务器】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 1 【部署到服务器】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 1 【部署到服务器】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 2【gitlab到底咋配置】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 2【gitlab到底咋配置】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 2【gitlab到底咋配置】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 4【gitlab-runner在gitlab上要如何配置】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 4【gitlab-runner在gitlab上要如何配置】
【实测】用土话让你明白如何做测试平台的持续部署和集成 - 4【gitlab-runner在gitlab上要如何配置】
一线实践 | 借助混沌工程工具 ChaosBlade 构建高可用的分布式系统
在分布式架构环境下,服务间的依赖日益复杂,可能没有人能说清单个故障对整个系统的影响,构建一个高可用的分布式系统面临着很大挑战。在可控范围或环境下,使用 ChaosBlade 工具,对系统注入各种故障,持续提升分布式系统的容错和弹性能力,以构建高可用的分布式系统。
11561 0