Geo data types support

原文：https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html

Geo data types support

地理数据类型是一个或多个 GitLab 功能存储相关信息所需的特定数据类别.

要使用 Geo 复制这些功能生成的数据，我们使用几种策略来访问，传输和验证它们.

Data types

当前，我们区分三种不同的数据类型：

请参阅下面列出的我们复制的每个功能或组件，其对应的数据类型，复制和验证方法的列表：

Type 功能/组件 复制方式 验证方式
Database PostgreSQL 中的应用程序数据 Native Native
Database Redis N/A (1) N/A
Database Elasticsearch Native Native
Database 个人摘要 PostgreSQL 复制 PostgreSQL 复制
Database 项目摘要 PostgreSQL 复制 PostgreSQL 复制
Database SSH 公钥 PostgreSQL 复制 PostgreSQL 复制
Git 项目资料库 地理与吉塔利 Gitaly 校验和
Git 项目 Wiki 资料库 地理与吉塔利 Gitaly 校验和
Git 项目设计资料库 地理与吉塔利 Gitaly 校验和
Git 用于分支项目重复数据删除的对象池 地理与吉塔利 未实现
Blobs User uploads (filesystem) 带有 API 的地理位置 未实现
Blobs 用户上传（对象存储） 具有 API /托管的地理区域（ 2 ） 未实现
Blobs LFS 对象（文件系统） 带有 API 的地理位置 未实现
Blobs LFS 对象（对象存储） 具有 API /托管的地理区域（ 2 ） 未实现
Blobs CI 作业工件（文件系统） 带有 API 的地理位置 未实现
Blobs CI 作业工件（对象存储） 具有 API /托管的地理区域（ 2 ） 未实现
Blobs 归档的 CI 构建跟踪（文件系统） 带有 API 的地理位置 未实现
Blobs 归档的 CI 构建跟踪（对象存储） 具有 API /托管的地理区域（ 2 ） 未实现
Blobs 容器注册表（文件系统） 使用 API​​ / Docker API 进行地理定位 未实现
Blobs 容器注册表（对象存储） 带有 API / Managed / Docker API 的 Geo（ 2 ） 未实现
Blobs 程序包注册表（文件系统） 带有 API 的地理位置 未实现
Blobs 程序包注册表（对象存储） 具有 API /托管的地理区域（ 2 ） 未实现
  • （ 1 ）：Redis 复制可与 Redis 前哨一起用作 HA 的一部分. 在地理节点之间不使用它.
  • （ 2 ）：对象存储复制可以通过 Geo 或您的对象存储提供者/设备本机复制功能来执行.

Git repositories

一个 GitLab 实例可以具有一个或多个存储库分片. 每个分片都有一个 Gitaly 实例，该实例负责允许对本地存储的 Git 存储库进行访问和操作. 它可以在具有单个磁盘，作为单个安装点安装多个磁盘（如 RAID 阵列）或使用 LVM 的计算机上运行.

它不需要特殊的文件系统，并且可以与 NFS 或已安装的 Storage Appliance 一起使用（使用远程文件系统时可能会有性能限制）.

通过 Gitaly 自己的 gRPC API 完成通信. 有三种可能的同步方式：

  • 使用常规的 Git 从一个 Geo 节点到另一个 Geo 节点的克隆/获取（具有特殊身份验证）.
  • 使用存储库快照（用于第一种方法失败或存储库损坏时）.
  • 从管理界面手动触发（上述两者的组合）.

每个项目最多可以有 3 个不同的存储库：

  • 一个项目存储库，其中存储了源代码.
  • Wiki 存储库，用于存储 Wiki 内容.
  • 一个设计库，在其中对设计工件进行索引（资产实际上在 LFS 中）.

他们都住在同一个碎片，并用共享相同的基础名称-wiki和-design用于 Wiki 以及设计资源库的情况下后缀.

Blobs

GitLab 将文件和 Blob（例如 Issue 附件或 LFS 对象）存储到以下任一位置：

  • 特定位置的文件系统.
  • 对象存储解决方案. 对象存储解决方案可以是：
    • 像 Amazon S3 Google Cloud Storage 一样基于云.
    • 由您托管（如 MinIO）.
    • 公开与对象存储兼容的 API 的存储设备.

当使用文件系统存储而不是对象存储时，如果使用多个服务器，则需要使用网络安装的文件系统来运行 GitLab.

关于复制和验证：

  • 我们使用内部 API 请求传输文件和 Blob.
  • 使用对象存储，您可以：
    • 使用云提供程序复制功能.
    • 让 GitLab 为您复制它.

Database

对于不同的用例，GitLab 依赖于存储在多个数据库中的数据. PostgreSQL 是 Web 界面中用户生成的内容（例如问题内容，​​注释以及权限和凭据）的唯一事实.

PostgreSQL 还可以保存某种程度的缓存数据，例如 HTML 呈现的 Markdown，缓存的合并请求差异（也可以配置为卸载到对象存储中）.

我们使用 PostgreSQL 自己的复制功能将数据从主节点复制到辅助节点.

我们将 Redis 用作缓存存储并为我们的后台作业系统保留持久性数据. 由于这两个用例都具有同一地理节点专有的数据，因此我们不在节点之间复制它.

Elasticsearch 是一个可选数据库，可以启用高级搜索功能，例如源代码级别的改进的全局搜索以及”问题/合并请求”和讨论中用户生成的内容. 目前，Geo 不支持此功能.

Limitations on replication/verification

下表列出了 GitLab 功能及其在辅助节点上的复制和验证状态.

您可以跟踪实现这些史诗/问题中缺少的项目的进度：

危险：不在此列表上或”已复制”列中具有” 否”的功能不会在辅助节点上复制. 如果不从这些功能中手动复制数据而进行故障转移，将导致数据丢失 . 如果希望在辅助节点上使用这些功能或成功执行故障转移，则必须使用其他方法复制它们的数据.

Feature 复制（在 GitLab 版本中添加） 已验证（在 GitLab 版本中添加） Notes
PostgreSQL 中的应用程序数据 Yes (10.2) Yes (10.2)
项目资料库 Yes (10.2) Yes (10.7)
项目 Wiki 资料库 Yes (10.2) Yes (10.7)
项目设计资料库 Yes (12.7) No
Uploads Yes (10.2) No 仅在转移时验证，或手动验证（ 1 ）
LFS 对象 Yes (10.2) No 仅在转移时验证，或手动验证（ 1 ）. 在 11.11.x 和 12.0.x（ 2 ）中的新 LFS 对象不可用.
CI 作业工件（痕迹除外） Yes (10.4) No 仅手动验证（ 1 ）
存档的痕迹 Yes (10.4) No 仅在转移时验证，或手动验证（ 1 ）
个人摘要 Yes (10.2) Yes (10.2)
Versioned snippets No No
项目摘要 Yes (10.2) Yes (10.2)
用于分支项目重复数据删除的对象池 Yes No
Server-side Git hooks No No
Elasticsearch integration No No
GitLab Pages No No
Container Registry Yes (12.3) No
NPM Registry Yes (13.2) No
Maven Repository Yes (13.2) No
Conan Repository Yes (13.2) No
NuGet Repository Yes (13.2) No
PyPi Repository Yes (13.2) No
Composer Repository Yes (13.2) No
External merge request diffs No No
Terraform State No(3) No
Vulnerability Export No(3) No
对象存储中的内容 Yes (12.4) No