CI 미러 테이블

GitLab 데이터베이스 분리 과정에서 main 데이터베이스와 CI 데이터베이스 간의 조인 문제를 해결하기 위해 도입된 CI 미러 테이블의 구조, 동기화 방식, 일관성 검사 메커니즘을 설명합니다.

문제 정의 # 데이터베이스 분리 작업 의 일환으로, GitLab이 사용하는 단일 데이터베이스를 main 과 ci 라는 두 개의 데이터베이스로 분리하는 것이 목표였으며, 이 과정에서 main 테이블과 ci 테이블 간의 조인을 모두 제거해야 하는 큰 과제가 생겼습니다. 이는 PostgreSQL이 서로 다른 데이터베이스에 속한 테이블 간의 조인을 지원하지 않기 때문입니다. 그러나 main 데이터베이스의 일부 핵심 애플리케이션 모델은 CI 측에서 매우 자주 조회됩니다. 예를 들어: namespaces 테이블의 Namespace . projects 테이블의 Project . 이러한 테이블에 대해 조인 을 수행할 수 없다는 점은 큰 과제입니다. 팀은 이 테이블들을 main 데이터베이스에서 CI 데이터베이스로 논리적으로 복제하여 다음과 같은 새 테이블을 만들기로 결정했습니다: namespaces 테이블의 미러인 ci_namespace_mirrors projects 테이블의 미러인 ci_project_mirrors 이 논리적 복제는 두 가지를 의미합니다: main 데이터베이스 테이블은 namespaces 및 projects 테이블과 조인하여 조회할 수 있습니다. ci 데이터베이스 테이블은 ci_namespace_mirrors 및 ci_project_mirrors 테이블과 조인할 수 있습니다. graph LR subgraph "Main database (tables)" A[namespaces] -->|updates| B[namespaces_sync_events] A -->|deletes| C[loose_foreign_keys_deleted_records] D[projects] -->|deletes| C D -->|updates| E[projects_sync_events] end B --> F C --> G E --> H subgraph "Sidekiq worker jobs" F[Namespaces::ProcessSyncEventsWorker] G[LooseForeignKeys::CleanupWorker] H[Projects::ProcessSyncEventsWorker] end F -->|do update| I G -->|delete records| I G -->|delete records| J H -->|do update| J subgraph "CI database (tables)" I[ci_namespace_mirrors] J[ci_project_mirrors] end 이 복제는 각 모델에서 필요한 몇 가지 속성에만 제한됩니다: Namespace 에서는 traversal_ids 를 복제합니다. Project 에서는 프로젝트가 속한 그룹을 나타내는 namespace_id 만 복제합니다. CI 미러 테이블을 소스 테이블과 동기화 유지 # 소스 테이블과 타깃 테이블을 동기화 상태로 유지하려면 다음과 같은 세 가지 유형의 이벤트를 처리해야 합니다: 새로운 네임스페이스 또는 프로젝트 생성. 네임스