应急响应处置之GitLab异常

Gitlab介绍：GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务

Gitlab服务构成：

1. Nginx：静态Web服务器
2. gitlab-shell：用于处理Git命令和修改authorized keys列表
3. gitlab-workhorse：轻量级的反向代理服务器(这个是个敏捷的反向代理，它会处理一些大的HTTP请求，比如文件的上传下载，其他的请求会反向代理给Gitlab Rails应用)
4. logrotate：日志文件管理工具
5. postgresql：数据库
6. redis：缓存数据库
7. sidekiq：用于在后台执行队列的任务
8. 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异常