拓扑园

  • Oracle性能优化
  • Oracle项目案例
    • Oracle近期项目案例(目录)
    • Oracle实战问题解析(目录)
    • Oracle数据库名变更流程(2种方式)
    • Oracle数据库目录更换流程(使用Oracle的clone工具)
    • Oracle数据库迁移方案(目录)
    • 标准化文档系列
  • Oracle基础知识
    • LLL的Oracle培训(分类)
    • LLL的docker培训(分类)
    • 标准化文档系列--(分类)
    • Oracle核心经典分析(分类)
    • 图灵小队----(分类并包含以下文章)
    • --MySQL8.0/Oracle/Memcached/Redis等安装配置于RHEL/OL6/7/8.X系列-运行环境最优配置
    • --PG安装配置于RHEL/9X系列-运行环境最优配置
    • --自动维护任务详解-开启、关闭信息统计收集(统计信息)
    • --图灵小队—Oracle/PostgreSQL下创建一个用户测试表(自行定义数据行)
    • --图灵小队-Oracle存储过程导出表的明细_UTL_FILE(文章)
    • --图灵小队-Oracle数据库删除/卸载操作指南(文章)
    • --图灵小队-Oracle常用性能查询SQL语句(文章)
    • --图灵小队-Oracle数据库上线前检查(文章)
    • --图灵小队-Oracle常用SQL语句(文章)
    • --图灵小队-Oracle脚本合集(文章)
    • --图灵小队-Oracle技巧记录(文章)
    • ADG
    • RAC
    • ASM
    • OGG
    • RMAN
    • EXPDP/IMPDP
    • 工厂数据导入导出系列
  • MySQL相关
  • Linux
    • kubernetes
    • docker
    • Linux
    • PHP
    • Nginx
    • haproxy
    • mail
    • 网站
    • 域名
    • 网址收藏
  • 数据中心
    • 新框架系统集合
    • 工作文档
    • EBS数据文件扩容
    • VMware虚拟化
    • EBS系列
    • 大数据
    • SVN
    • zabbix
    • SAP
    • 备份相关
    • FC交换机
    • SVN
  • K-Studing
    • LG-MySQL
    • LG-Docker/K8S
    • LG-PostgreSQL
    • LG-ORACLE_BBED
    • LG-ORACLE
    • LG-Elasticsearch(ES)+ELK
    • Oracle-19C-OCP
    • WERN_ORACLE培训
    • redis数据库
    • Nginx培训学习系列
  • 其他
    • 外研英语4年级下册-听力
    • 影视系列
    • 如何使用iTunes软件通过抓包下载旧版本的ios的app
Oracle数据库恢复专家团队:TEL:18562510581(微信同号);QQ:284833194;QQ群:496333360
天高任鸟飞
  1. 首页
  2. 数据中心
  3. SAP
  4. 正文

美云app群组丢失问题解决步骤-2021-04-06

2021年4月6日 415点热度 0人点赞 0条评论

目录

  • 美信云移动APP群组数据丢失问题处理
    • 一、问题分析
    • 二、深度分析:
    • 三、解决方案
      • 1、方案1(在有redis-dump工具下使用)
        • (1)安装redis-dump
        • (2)将172.18.2.63的appendonly_20210708070002.aof文件拷贝出来
        • (3)在172.18.5.149,用新拷贝的appendonly.aof覆盖原来的
        • (4)重启redis服务
        • (5)使用redis-dump导出数据
        • (6)使用redis-load导入数据
        • (7)如果不重启redis,其他服务不用动
      • (8)恢复完成
      • 2、方案2(在没有redis-dump的工具下考虑使用)
        • (1)关闭172.18.2.63的redis服务
        • (2)找到/apps/backup中的aof文件,查看最早的没有的丢失数据的文件备份。
        • (3)重启redis服务
        • (4)进入数据库查看是否群组是43个
        • (5)重启后,美云app电脑端可能会不断上线、下线,需要重启如下服务:
    • 前后端查看对比与分析

美信云移动APP群组数据丢失问题处理

一、问题分析

1、查看redis数据的db9和db10数据丢失

2、查看mysql数据正常

3、查看app前台所有之前的群都不存在,但是还可以正常发送群信息

4、查看后台web管理所有群都存在,但是查看群成员不存在

二、深度分析:

  • 通过跟踪日志,发现移动app的后端群组服务的配置文件:/apps/svr/im/group/im_server/imgroup_server/dbproxy.conf中,群组配置连接到63的redis数据库中。进而排查redis数据库
#GroupMember
group_member_host=172.18.2.63
group_member_port=4501
group_member_db=9
group_member_password=123456
group_member_maxconncnt=96

#MemberGroup
member_group_host=172.18.2.63
member_group_port=4501
member_group_db=10
member_group_password=123456
member_group_maxconncnt=96

 

  • 通过上述配置文件,检查redis 数据库的9和10库,发现数据库数据为0,
  • 由上可以确认,redis的数据已经被删除了,具体原因是redis的aof数据做了内存限制,快到定点时,会清理长时间不用的信息,db9,db10是群组信息,被清理了,改大redis.conf的maxmemory 4096mb值即可
  • 当前方式有两种思路:
    1. 重新让redis加载mysql中的数据(不确定如何关联)
    2. 用之前的备份恢复redis这两个库的数据
  • 解决方法如下:

三、解决方案

1、方案1(在有redis-dump工具下使用)

恢复之前群组存在的备份,导出redis的db9和db10的数据

需要安装redis-dump(在centos7安装,在centos6安装少liff-devel依赖,无法yum安装)

(1)安装redis-dump

https://www.topunix.com/post-3707.html

(2)将172.18.2.63的appendonly_20210708070002.aof文件拷贝出来

scp -r/backup/Redis root@172.18.5.149:/tmp

(3)在172.18.5.149,用新拷贝的appendonly.aof覆盖原来的

cp /tmp/Redis/appendonly_20210727070001.aof ./appendonly.aof

(4)重启redis服务

 /usr/local/redis/bin/redis-server /usr/local/redis/redis_4501/redis.conf

(5)使用redis-dump导出数据

导出:

redis-dump -u 172.18.5.149:4501 -a 123456 -d 9 >db9.json
redis-dump -u 172.18.5.149:4501 -a 123456 -d 10 >db10.json

(6)使用redis-load导入数据

导入:

cat db9.json | redis-load -u 172.18.2.63:4501 -a 123456 -d 9
cat db10.json | redis-load -u 172.18.2.63:4501 -a 123456 -d 10

再次去查看redis数据,数据成功恢复。

(7)如果不重启redis,其他服务不用动

如果重启redis,需要把2.58的8301服务重启一下

[apps@MX_IM_PRD ~]$ ps -ef|grep msg
apps 6861 6833 0 15:19 pts/0 00:00:00 grep msg
apps 31822 1 0 Mar02 ? 05:20:03 /apps/svr/im/msg/bin/msgd -c /apps/svr/im/msg/cfg/8301.cfg
[apps@MX_IM_PRD ~]$ kill -9 31822

apps@MX_IM_PRD ~]$ /apps/svr/im/msg/bin/msgd -c /apps/svr/im/msg/cfg/8301.cfg &

(8)恢复完成

2、方案2(在没有redis-dump的工具下考虑使用)

将备份的aof文件进行恢复即可。步骤如下:

(1)关闭172.18.2.63的redis服务

su - apps

ps -ef|grep redis
kill -9 id

(2)找到/apps/backup中的aof文件,查看最早的没有的丢失数据的文件备份。

su - apps
cp /apps/backup/Redis/appendonly_20210330070001.aof  /apps/svr/redis/redis_4501/appendonly.aof

(3)重启redis服务

/apps/svr/redis/bin/redis-server /apps/svr/redis/redis_4501/redis.conf
/apps/svr/redis/bin/redis-sentinel /apps/svr/redis/sentinel_24501/sentinel.conf

(4)进入数据库查看是否群组是43个

ip:172.18.2.63

端口:4501

密码:123456

(5)重启后,美云app电脑端可能会不断上线、下线,需要重启如下服务:

172.18.2.58的msg服务

[apps@MX_IM_PRD ~]$ ps -ef|grep msg
apps 6861 6833 0 15:19 pts/0 00:00:00 grep msg
apps 31822 1 0 Mar02 ? 05:20:03 /apps/svr/im/msg/bin/msgd -c /apps/svr/im/msg/cfg/8301.cfg
[apps@MX_IM_PRD ~]$ kill -9 31822

apps@MX_IM_PRD ~]$ /apps/svr/im/msg/bin/msgd -c /apps/svr/im/msg/cfg/8301.cfg &
[1] 6961
[apps@MX_IM_PRD ~]$ 2021-04-06 15:20:23,841:6961(0x2add80401700):ZOO_INFO@log_env@726: Client environment:zookeeper.version=zookeeper C client 3.4.10
2021-04-06 15:20:23,841:6961(0x2add80401700):ZOO_INFO@log_env@730: Client environment:host.name=MX_IM_PRD
2021-04-06 15:20:23,841:6961(0x2add80401700):ZOO_INFO@log_env@737: Client environment:os.name=Linux
2021-04-06 15:20:23,841:6961(0x2add80401700):ZOO_INFO@log_env@738: Client environment:os.arch=2.6.32-642.el6.x86_64
2021-04-06 15:20:23,841:6961(0x2add80401700):ZOO_INFO@log_env@739: Client environment:os.version=#1 SMP Tue May 10 17:27:01 UTC 2016
2021-04-06 15:20:23,863:6961(0x2add80401700):ZOO_INFO@log_env@747: Client environment:user.name=root
2021-04-06 15:20:23,863:6961(0x2add80401700):ZOO_INFO@log_env@755: Client environment:user.home=/home/apps
2021-04-06 15:20:23,863:6961(0x2add80401700):ZOO_INFO@log_env@767: Client environment:user.dir=/home/apps
2021-04-06 15:20:23,863:6961(0x2add80401700):ZOO_INFO@zookeeper_init@800: Initiating client connection, host=172.18.2.60:2181 sessionTimeout=30000 watcher=0x496547 sessionId=0 sessionPasswd=<null> context=(nil) flags=0
2021-04-06 15:20:23,864:6961(0x2addbc41e700):ZOO_INFO@check_events@1728: initiated connection to server [172.18.2.60:2181]
2021-04-06 15:20:23,865:6961(0x2addbc41e700):ZOO_INFO@check_events@1775: session establishment complete on server [172.18.2.60:2181], sessionId=0x174b59131adfc02, negotiated timeout=30000
2021-04-06 15:20:23,866:6961(0x2add80401700):ZOO_INFO@zookeeper_close@2527: Closing zookeeper sessionId=0x174b59131adfc02 to [172.18.2.60:2181]

 

 

前后端查看对比与分析

1、导入后,查看redis43个群

2、web前端显示50个群。

3、mysql数据库查看,有71个群,其中状态为0的为21个(状态为零代表前端已经解散了的群);还有50个群状态为1.

4、50个群与redis43个不一致。

经分析,其中7个群是初始化创建的群,没有成员,没有经过前端创建群,所以redis没有此数据的存储。

50-7=43个群,是一致的,支持问题解决。

 

本作品采用 知识共享署名 4.0 国际许可协议 进行许可
标签: 暂无
最后更新:2021年7月29日

admin

这个人很懒,什么都没留下

打赏 点赞
< 上一篇
下一篇 >

文章评论

您需要 登录 之后才可以评论

COPYRIGHT © 2022 拓扑园. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

鲁ICP备2021020523号

鲁ICP备2021020523号