Gitlab介绍:GitLab 是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的Web服务
Gitlab服务构成:
- Nginx:静态Web服务器
- gitlab-shell:用于处理Git命令和修改authorized keys列表
- gitlab-workhorse:轻量级的反向代理服务器(这个是个敏捷的反向代理,它会处理一些大的HTTP请求,比如文件的上传下载,其他的请求会反向代理给Gitlab Rails应用)
- logrotate:日志文件管理工具
- postgresql:数据库
- redis:缓存数据库
- sidekiq:用于在后台执行队列的任务
- unicorn:Gitlab Rails应用是托管在这个服务器上面的
异常回顾:
一、15:06分,接收到反馈,gitlab服务器异常,502 ,服务无法正常访问:
1.查看gitlab服务容器,服务正常
2.查看异常日志:
3.查看postgresql服务,进入容器查看数据库状态,
Public数据不存在,数据库缺失。
对比老gitlab服务器postgresql数据库
4.postgresql采用容器部署,数据库持久化到sfs共享存储里,初步判断共享存储未挂载上,导致数据库不可读
5.其他同事新建gitlab,定位缺失表以及缺失原因。
二、排查:
1.新建postgresql数据库,恢复老数据,重启容器,发现数据依旧丢失
2.进postgresql容器,发现sfs存储并未挂载
3.紧急备份所有仓库数据,为数据还原做准备。
三、数据还原
1.新建gitlab服务,将postgresql数据库迁移到阿里云服务,redis采用华为云服务
2.利用gitlab老备份数据进行还原
3.使用新仓库数据,进行覆盖
4.发现新建项目不存在,原项目数据正常。
四、定位sfs共享不存在问题
1.在本地docker下新建postgresql服务,挂载本地目录到容器,配置为:/postgresql:/var/lib/postgresql
容器中发现,不存在此挂载路径
查看postgresql数据库/var/lib/postgresql/data目录,数据正常,postgresql服务正常。
2.同事反馈,在阿里云上新建的postgresql数据库,挂载路径加data就无法启动
3.在本地测试挂载:
同样无法正常启动,异常提示数据目录已存在不为空,无法进行数据初始化。
4.在本地新增二级目录进行挂载
发现了一个大问题,PG数据库下存在2个路径,一个是/var/lib/postgresql,另外一个是/var/lib/postgresql/data
而数据库存在/var/lib/postgresql/data 目录下,本地挂载的目录路径为/var/lib/postgresql 目录。在持久化数据目录为空。
5.至此发现数据丢失原因:
容器在挂载的时候,只是将挂载路径挂载到了/var/lib/postgresql下,容器中将数据库存在/var/lib/postgresql/data 目录下,两个是完全不同的挂载点。
三、血的教训:
1.数据备份机制不全,未能在异常时第一时间恢复
2.容器配置异常,挂载应当按照容器的变量路径进行挂载,导致容器在重启的时候,进行了初始化操作。
3.测试的时候,只是在PG服务配置的时进行了重启验证,gitlab服务配置完成后,应该是未重启过PG服务。
4.应急演练不足,未能在日常进行一些重要服务的演练,演练方案应当包括:服务高可用测试,服务异常快速响应,应急数据恢复,容灾数据恢复,
四:后续数据处理
1.测试将hash存储恢复到传统存储,数据库存在的项目进行了转化,项目数据可在仓库下查看,新建项目因元数据丢失,系统无法自动转换。不过也发现,未进行转换的数据在hash存储下依然存在。
2.新建项目数据丢失恢复待测试方案:
项目的仓库数据通过hash方式存储,通过将hash数据地址反向解析出项目以及路径,将元数据通过数据库进行补充完成,然后在进行hash存储转换,测试是否可以正常自动转为为传统存储。
如果可以转换为传统存储,将项目内容导出,在导入到新服务,数据即可全部恢复。
文章转载请说明出处:八零岁月 » 应急响应处置之GitLab异常
评论前必须登录!