gitlab数据库
摘要:如何在GitLab中还原意外删除的数据库? 我们如何实现数据库备份,恢复,容灾和高可用性? 如果您从事数据库行业,那么您最近可能会更担心这些问题。 去年年底,包括炉石数据丢失和MongoDB黑客勒索在内的事件突显了这一消息。 最近,另一个事件引起了人们的关注:rm -rf命令意外删除了GitLab数据库中的数据文件。如何在GitLab中还原意外删除的数据库? 我们如何实现数据库备份,恢复,容灾和高可用性? 如果您从事数据库行业,那么您最近可能会更担心这些问题。 去年年底,包括炉石数据丢失和MongoDB黑客勒索在内的事件突显了这一消息。 最近,另一个事件引起了人们的关注:rm -rf命令意外删除了GitLab数据库中的数据文件。
数据库对于任何企业都是至关重要的。 Web SQL注入和意外删除数据不仅损害业务,还可能导致用户信息泄漏。 许多公司意识到数据库安全性的重要性,并拥有专门的数据库管理员(DBA)进行数据维护。 DBA家族就像IT世界中的边境勇士一样,保护数据是DBA最重要的职责之一。 但是,尽管DBA采取了许多有效措施,但事故确实发生了。 有时,太多的操作界面和服务之间频繁的来回切换可能会导致人为错误率上升。
即使意外删除后,我们如何确保数据文件的安全?
多份副本–高可用性(HA)保证不会意外删除在许多传统企业中,实现HA的常见方法是在多个主机之间安装共享存储。 实际上,只有一个数据副本可用,因为存储的可用性比服务器要高得多。 这种HA方法的优势在于其结构的简单性,从而更容易实现数据一致性。
[IMG] https://cdn-images-1.medium.com/max/800/1*ApyZGeMke2TU7pBJzBCmeg.png [/ IMG]
这种HA方法的缺点很明显:存在单点故障。 当然,您可以使用多个存储设备或物理映像来解决单点故障问题。 另一方面,由于只有一个存储副本或整个映像有多个副本,因此数据删除具有传染性。 也就是说,您可以删除全部或全部数据,这使得在GitLab中执行rm -rf操作时很难保护数据。
高可用性和灾难容忍的多个副本
从v9.1开始,Pos