문제 설명
비동기 접근
- 작동 방식
scripts/decomposition/generate-loose-foreign-key
마이그레이션 및 구성 예제
테스트
느슨한 외부 키의 주의사항
- 레코드 생성
- 관련 조회
dependent: :destroy 및 dependent: :nullify에 대한 참고
느슨한 외래 키의 위험 및 가능한 완화 방안
아키텍처
- 데이터베이스 구조
문제 해결
- 삭제된 레코드의 축적
- PartitionManager 버그

느슨한 외부 키

문제 설명

관계형 데이터베이스(포스트그리SQL 포함)에서 외부 키는 두 개의 데이터베이스 테이블을 연결하고 데이터 일관성을 보장하는 방법을 제공합니다. GitLab에서는 외부 키가 데이터베이스 설계 프로세스의 중요한 부분입니다. 대부분의 데이터베이스 테이블에는 외부 키가 있습니다.

진행 중인 데이터베이스 분해 작업에서 연결된 레코드는 두 개의 다른 데이터베이스 서버에 존재할 수 있습니다. PostgreSQL은 네트워크를 통해 두 개의 다른 데이터베이스 서버 간에 데이터 일관성을 보장하지 못합니다. PostgreSQL은 단일 데이터베이스 서버 내에서 작동하는 외부 키를 지원하지 않으며 두 개의 다른 데이터베이스 서버 간에 있는 두 데이터베이스 테이블 간의 연결을 정의하지 않습니다.

예시:

데이터베이스 “Main”: projects 테이블
데이터베이스 “CI”: ci_pipelines 테이블

프로젝트는 여러 파이프라인을 가질 수 있습니다. 프로젝트가 삭제될 때 연결된 ci_pipeline (via the project_id column) 레코드도 삭제되어야 합니다.

멀티 데이터베이스 설정에서는 외부 키로 이를 달성할 수 없습니다.

비동기 접근

우리가 선호하는 이 문제 해결 방법은 최종적인 일관성입니다. 느슨한 외부 키 기능을 통해 지연된 연관 정리를 구성할 수 있으며, 이로 인해 애플리케이션 성능에 부정적인 영향을 미치지 않습니다.

작동 방식

이전 예제에서 projects 테이블의 레코드는 여러 ci_pipeline 레코드를 가질 수 있습니다. 정리 프로세스를 실제 부모 레코드 삭제와 분리하기 위해 우리는:

projects 테이블에 DELETE 트리거를 생성합니다. 별도의 테이블(deleted_records)에 삭제 사항을 기록합니다.
작업은 매 분 또는 두 분마다 deleted_records 테이블을 확인합니다.
테이블의 각 레코드에 대해 project_id 열을 사용하여 연관된 ci_pipelines 레코드를 삭제합니다.

이 절차가 작동하려면 비동기적으로 정리할 테이블을 등록해야 합니다.

`scripts/decomposition/generate-loose-foreign-key`

우리는 외부 키를 느슨한 외부 키로 이주하는 데 도움이 되는 자동화 도구를 만들었습니다. 이것은 분해 노력의 일부로 외부 키를 자동으로 느슨한 외부 키로 변환할 수 있도록 기존 키를 제시하고 선택한 외부 키를 자동으로 변환합니다. 이는 외부 키와 느슨한 외부 키 정의 사이의 일관성을 보장하고, 올바르게 테스트되도록 합니다.

외부 키를 느슨한 외부 키로 교환하는 데 자동화 스크립트를 사용할 것을 강력히 권장합니다.

이 도구는 외부 키를 교환하는 모든 측면을 보장합니다. 이에는 다음이 포함됩니다:

외부 키를 제거하는 마이그레이션 생성
새로운 마이그레이션으로 db/structure.sql 업데이트
새로운 느슨한 외부 키를 추가하기 위해 config/gitlab_loose_foreign_keys.yml 업데이트
느슨한 외부 키가 올바르게 지원되도록 모델의 스펙을 생성하거나 업데이트

이 도구는 scripts/decomposition/generate-loose-foreign-key에 위치해 있습니다:

$ scripts/decomposition/generate-loose-foreign-key -h

Usage: scripts/decomposition/generate-loose-foreign-key [options] <filters...>
    -c, --cross-schema               Show only cross-schema foreign keys
    -n, --dry-run                    Do not execute any commands (dry run)
    -r, --[no-]rspec                 Create or not a rspecs automatically
    -h, --help                       Prints this help

교차 스키마 외부 키의 이주에 대한 마이그레이션을 위해, 아직 마이그레이션하지 않은 외부 키를 표시하기 위해 -c 수정자를 사용합니다:

$ scripts/decomposition/generate-loose-foreign-key -c
Re-creating current test database
Dropped database 'gitlabhq_test_ee'
Dropped database 'gitlabhq_geo_test_ee'
Created database 'gitlabhq_test_ee'
Created database 'gitlabhq_geo_test_ee'

Showing cross-schema foreign keys (20):
   ID | HAS_LFK |                                     FROM |                   TO |                         COLUMN |       ON_DELETE
    0 |       N |                                ci_builds |             projects |                     project_id |         cascade
    1 |       N |                         ci_job_artifacts |             projects |                     project_id |         cascade
    2 |       N |                             ci_pipelines |             projects |                     project_id |         cascade
    3 |       Y |                             ci_pipelines |       merge_requests |               merge_request_id |         cascade
    4 |       N |                   external_pull_requests |             projects |                     project_id |         cascade
    5 |       N |                     ci_sources_pipelines |             projects |                     project_id |         cascade
    6 |       N |                                ci_stages |             projects |                     project_id |         cascade
    7 |       N |                    ci_pipeline_schedules |             projects |                     project_id |         cascade
    8 |       N |                       ci_runner_projects |             projects |                     project_id |         cascade
    9 |       Y |             dast_site_profiles_pipelines |         ci_pipelines |                 ci_pipeline_id |         cascade
   10 |       Y |                   vulnerability_feedback |         ci_pipelines |                    pipeline_id |         nullify
   11 |       N |                             ci_variables |             projects |                     project_id |         cascade
   12 |       N |                                  ci_refs |             projects |                     project_id |         cascade
   13 |       N |                       ci_builds_metadata |             projects |                     project_id |         cascade
   14 |       N |                ci_subscriptions_projects |             projects |          downstream_project_id |         cascade
   15 |       N |                ci_subscriptions_projects |             projects |            upstream_project_id |         cascade
   16 |       N |                      ci_sources_projects |             projects |              source_project_id |         cascade
   17 |       N |         ci_job_token_project_scope_links |             projects |              source_project_id |         cascade
   18 |       N |         ci_job_token_project_scope_links |             projects |              target_project_id |         cascade
   19 |       N |                ci_project_monthly_usages |             projects |                     project_id |         cascade

외부 키(FK)에 대응하려면 FROM/TO/COLUMN에 대해 일치시키기 위해 하나 이상의 필터를 작성하세요:

- scripts/decomposition/generate-loose-foreign-key (filters...)
- scripts/decomposition/generate-loose-foreign-key ci_job_artifacts project_id
- scripts/decomposition/generate-loose-foreign-key dast_site_profiles_pipelines

명령은 외부 키 생성을 위해 일치시키기 위해 정규 표현식 디렉터리을 받습니다. 예를 들어, 분해된 데이터베이스의 ci_job_token_project_scope_links에 대한 모든 외부 키를 교환하려면 다음을 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c ci_job_token_project_scope_links

분해된 데이터베이스의 ci_job_token_project_scope_links의 source_project_id만 교환하려면 다음을 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c ci_job_token_project_scope_links source_project_id

테이블이나 컬럼의 정확한 이름에 대한 일치를 위해 정규 표현식 위치 앵커 ^와 $를 사용할 수 있습니다. 예를 들어, 이 명령은 events 테이블에 대한 외부 키만 일치시키지만 테이블 incident_management_timeline_events에 대해 일치시키지 않습니다.

scripts/decomposition/generate-loose-foreign-key -n ^events$

새 브랜치를 생성하지 않고 외부 키 전체(모두가 _id를 추가한 것만)를 교환하고, 새로운 브랜치를 생성하지 않고 (변경만 커밋) RSpec 테스트를 생성하지 않으려면 다음을 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c --no-branch --no-rspec _id

projects를 참조하는 외부 키를 모두 교환하되(변경만 커밋) 새로운 브랜치를 생성하지 않으려면 다음을 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c --no-branch projects

마이그레이션 및 구성 예제

느슨한 외부 키 구성

느슨한 외부 키는 YAML 파일에 정의됩니다. 구성에는 다음 정보가 필요합니다.

상위 테이블 이름 (projects)
하위 테이블 이름 (ci_pipelines)
데이터 정리 방법 (async_delete 또는 async_nullify)

YAML 파일은 config/gitlab_loose_foreign_keys.yml에 위치해 있습니다. 파일은 하위 테이블의 이름으로 외부 키 정의를 그룹화합니다. 하위 테이블에는 여러 느슨한 외부 키 정의가 있을 수 있으므로, 배열로 저장합니다.

예제 정의:

ci_pipelines:
  - table: projects
    column: project_id
    on_delete: async_delete

만약 ci_pipelines 키가 이미 YAML 파일에 있다면, 새 항목을 배열에 추가할 수 있습니다:

ci_pipelines:
  - table: projects
    column: project_id
    on_delete: async_delete
  - table: another_table
    column: another_id
    on_delete: :async_nullify

레코드 변경 추적

projects 테이블에서 삭제 사항을 파악하려면 포스트-배포 마이그레이션을 사용하여 DELETE 트리거를 구성하세요. 트리거는 한 번만 구성하면 됩니다. 모델에 이미 적어도 하나의 loose_foreign_key 정의가 있는 경우에는 이 단계를 건너뛸 수 있습니다:

class TrackProjectRecordChanges < Gitlab::Database::Migration[2.1]
  include Gitlab::Database::MigrationHelpers::LooseForeignKeyHelpers
  
  def up
    track_record_deletions(:projects)
  end
  
  def down
    untrack_record_deletions(:projects)
  end
end

외부 키 제거

기존 외부 키가 있는 경우, 데이터베이스에서 제거할 수 있습니다. 이 외부 키는 projects와 ci_pipelines 테이블 간의 연결을 설명합니다:

ALTER TABLE ONLY ci_pipelines
ADD CONSTRAINT fk_86635dbd80
FOREIGN KEY (project_id)
REFERENCES projects(id)
ON DELETE CASCADE;

마이그레이션은 DELETE 트리거가 설치되고 느슨한 외부 키 정의가 배포된 후에 실행되어야 합니다. 따라서, 이것은 트리거에 대한 마이그레이션 이후의 날짜로 된 포스트-배포 마이그레이션이어야 합니다. 외부 키가 이전에 삭제된 경우, 매뉴얼 정리가 필요한 데이터 불일치 가능성이 높습니다:

class RemoveProjectsCiPipelineFk < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  
  def up
    with_lock_retries do
      remove_foreign_key_if_exists(:ci_pipelines, :projects, name: "fk_86635dbd80")
    end
  end
  
  def down
    add_concurrent_foreign_key(:ci_pipelines, :projects, name: "fk_86635dbd80", column: :project_id, target_column: :id, on_delete: "cascade")
  end
end

이 시점에서 설정 단계가 종료됩니다. 삭제된 projects 레코드는 예약된 정리 워커 작업에 의해 자동으로 가져와질 것입니다.

느슨한 외부 키 제거

느슨한 외부 키 정의가 더 이상 필요하지 않은 경우(상위 테이블이 제거된 경우 또는 FK가 복원된 경우), YAML 파일에서 정의를 제거하고 데이터베이스에 남은 삭제된 레코드를 제거해야 합니다.

구성에서 느슨한 외부 키 정의를 제거합니다 (config/gitlab_loose_foreign_keys.yml).

삭제 추적 트리거는 상위 테이블이 더 이상 느슨한 외부 키를 사용하지 않을 때만 제거해야 합니다. 모델에 여전히 적어도 하나의 loose_foreign_key 정의가 있는 경우에는 이러한 단계를 건너뛸 수 있습니다:

상위 테이블에서 트리거를 제거합니다(상위 테이블이 여전히 존재하는 경우).
loose_foreign_keys_deleted_records 테이블에서 남은 삭제된 레코드를 제거합니다.

트리거 제거를 위한 마이그레이션:

class UnTrackProjectRecordChanges < Gitlab::Database::Migration[2.1]
  include Gitlab::Database::MigrationHelpers::LooseForeignKeyHelpers
  
  def up
    untrack_record_deletions(:projects)
  end
  
  def down
    track_record_deletions(:projects)
  end
end

트리거 제거로 인해 loose_foreign_keys_deleted_records 테이블에 더 이상 레코드가 삽입되지 않도록합니다. 그러나 테이블에 남은 보류 중인 레코드가 있을 수 있습니다. 이러한 레코드는 인라인 데이터 마이그레이션을 사용하여 제거해야 합니다.

class RemoveLeftoverProjectDeletions < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  
  def up
    loop do
      result = execute <<~SQL
      DELETE FROM "loose_foreign_keys_deleted_records"
      WHERE
      ("loose_foreign_keys_deleted_records"."partition", "loose_foreign_keys_deleted_records"."id") IN (
        SELECT "loose_foreign_keys_deleted_records"."partition", "loose_foreign_keys_deleted_records"."id"
        FROM "loose_foreign_keys_deleted_records"
        WHERE
        "loose_foreign_keys_deleted_records"."fully_qualified_table_name" = 'public.projects' AND
        "loose_foreign_keys_deleted_records"."status" = 1
        LIMIT 100
      )
      SQL
      
      break if result.cmd_tuples == 0
    end
  end
  
  def down
    # no-op
  end
end

테스트

“it has loose foreign keys” 공유 예제를 사용하여 ON DELETE 트리거 및 느슨한 외부 키 정의의 존재 여부를 테스트할 수 있습니다.

모델 테스트 파일에 추가:

it_behaves_like 'it has loose foreign keys' do
  let(:factory_name) { :project }
end

외부 키를 제거한 후, “느슨한 외부 키에 의해 정리” 공유 예제를 사용하여 추가된 느슨한 외부 키를 통해 자식 레코드의 삭제 또는 널화를 테스트할 수 있습니다:

it_behaves_like 'cleanup by a loose foreign key' do
  let!(:model) { create(:ci_pipeline, user: create(:user)) }
  let!(:parent) { model.user }
end

느슨한 외부 키의 주의사항

레코드 생성

이 기능은 상위 레코드가 삭제된 후 해당 레코드를 효율적으로 정리하는 방법을 제공합니다. 외부 키가 없으면 새로운 관련 레코드를 생성할 때 애플리케이션이 상위 레코드가 존재하는지 확인해야 합니다.

나쁜 예: 주어진 ID로 레코드를 생성합니다 (project_id는 사용자 입력에서 가져옴). 이 예에서 우리는 무작위 프로젝트 ID를 전달하는 것을 막지 못합니다:

Ci::Pipeline.create!(project_id: params[:project_id])

좋은 예: 추가 검사를 수행하여 레코드를 생성합니다:

project = Project.find(params[:project_id])
Ci::Pipeline.create!(project_id: project.id)

`dependent: :destroy` 및 `dependent: :nullify`에 대한 참고

이러한 Rails 기능 대신 외부 키를 사용하는 것을 고려했지만, 여러 문제가 있습니다.

이것은 트랜잭션의 맥락에서 다른 연결로 실행됩니다 (허용하지 않는).
이로 인해 PostgreSQL에서 모든 레코드를로드하고 Ruby에서 루프를 돌며 개별 DELETE 쿼리를 호출하여 심각한 성능 저하가 발생할 수 있습니다.
이것은 destroy 메소드가 모델에 직접 호출될 때에만 해당되기 때문에 delete_all 및 다른 상위 테이블에서의 단계 삭제를 놓칠 수 있습니다.

데이터베이스 외부의 데이터를 정리해야 하는 복잡한 객체에 대해서는 dependent: :destroy를 사용하고 싶을 때 대안을 보려면 다음을 참조하세요. Avoid dependent: :nullify and dependent: :destroy across databases.

느슨한 외래 키의 위험 및 가능한 완화 방안

일반적으로, 느슨한 외래 키 아키텍처는 최종 일관성을 가지며 정리 지연 시간은 GitLab 사용자 또는 운영자에게 보이는 문제를 유발할 수 있습니다. 저희는 이러한 트레이드오프를 수용 가능하다고 여기지만, 문제가 너무 빈번하거나 심각할 경우에는 완화 전략을 시행해야 할 수 있습니다. 일반적인 완화 전략은 지연된 정리에 영향을 많이 미치는 레코드들의 ‘긴급한’ 대기열을 가져 두는 것이 될 수 있습니다.

아래에는 발생 가능한 문제에 대한 구체적인 예와 그에 따른 완화 방안이 몇 가지 나와 있습니다. 나열된 모든 경우에 대해 우리는 문제를 여전히 낮은 위험 및 낮은 영향으로 고려할 수 있으며, 이 경우에는 어떤 완화 조치도 시행하지 않을 수 있습니다.

레코드가 삭제되어야 하지만 뷰에 표시됨

이 가정적인 예는 다음과 같은 외래 키로 발생할 수 있습니다:

ALTER TABLE ONLY vulnerability_occurrence_pipelines
    ADD CONSTRAINT fk_rails_6421e35d7d FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;

이 예에서는 ci_pipelines 레코드와 연결된 모든 vulnerability_occurrence_pipelines 레코드를 삭제할 것으로 예상됩니다. 그러나 이 경우, GitLab의 취약점 페이지에 어떤 취약점이 발생했음을 나타내는 뷰를 만들 때, 파이프라인을 삭제하면 해당 발생을 모두 삭제해야 한다고 예상됩니다. 그러나 이 경우 파이프라인이 삭제되어 404 오류가 나타날 때가 있어, 그에 따라 발생도 함께 사라질 수 있습니다.

완화 방안

취약점 페이지에서 취약점 발생을 렌더링할 때 해당 파이프라인을 로드하고, 파이프라인을 찾지 못하면 해당 발생을 건너뛰도록 선택할 수 있습니다.

삭제된 상위 레코드가 뷰 렌더링에 필요하며 `500` 오류를 유발함

이 가정적인 예는 다음과 같은 외래 키로 발생할 수 있습니다:

ALTER TABLE ONLY vulnerability_occurrence_pipelines
    ADD CONSTRAINT fk_rails_6421e35d7d FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;

이 예에서는 ci_pipelines 레코드와 연결된 모든 vulnerability_occurrence_pipelines 레코드를 삭제할 것으로 예상됩니다. 그러나 이 경우, GitLab의 취약점 페이지에서 새로운 “발생”을 보여주게 됩니다. 그러나 이러한 발생을 렌더링할 때, 예를 들어 occurrence.pipeline.created_at을 렌더링하면 사용자에게 500 오류가 발생할 수 있습니다.

완화 방안

취약점 페이지에서 취약점 발생을 렌더링할 때 해당 파이프라인을 로드하고, 파이프라인을 찾지 못하면 해당 발생을 건너뛰도록 선택할 수 있습니다.

삭제된 상위 레코드가 Sidekiq 워커에서 액세스되어 작업 실패를 유발함

이 가정적인 예는 다음과 같은 외래 키로 발생할 수 있습니다:

ALTER TABLE ONLY vulnerability_occurrence_pipelines
    ADD CONSTRAINT fk_rails_6421e35d7d FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;

이 예에서는 ci_pipelines 레코드와 연결된 모든 vulnerability_occurrence_pipelines 레코드를 삭제할 것으로 예상됩니다. 그러나 이 경우, 취약점을 처리하는 Sidekiq 워커에서는 모든 발생을 처리하며 occurrence.pipeline.created_at을 실행하면 Sidekiq 작업이 실패할 수 있습니다.

완화 방안

Sidekiq 워커에서 취약점 발생을 반복하는 동안 해당 파이프라인을 로드하고, 파이프라인을 찾지 못하면 해당 발생을 처리를 건너뛰도록 선택할 수 있습니다.

아키텍처

느슨한 외래 키 기능은 LooseForeignKeys 루비 네임스페이스 내에서 구현됩니다. 해당 코드는 코어 응용프로그램 코드와 격리되어 있으며 이론적으로 독립적인 라이브러리가 될 수 있습니다.

이 기능은 오로지 LooseForeignKeys::CleanupWorker 워커 클래스를 통해서만 호출됩니다. 이 워커는 GitLab 인스턴스의 구성에 따라 스케줄이 설정된 크론 작업을 통해 호출됩니다.

분해되지 않은 GitLab (1개의 데이터베이스): 매분 호출됨.
분해된 GitLab (2개의 데이터베이스, CI 및 Main): 매분 호출되며, 한 번에 한 데이터베이스를 정리함. 예를 들어, 본 데이터베이스의 정리 워커는 매 2분마다 실행됨.

잠금 경합 및 동일한 데이터베이스 행의 처리를 방지하기 위해 워커는 병렬로 실행되지 않습니다. 이 동작은 레디스 잠금으로 보장됩니다.

레코드 정리 절차:

레디스 잠금 획득함.
정리할 데이터베이스를 결정함.
삭제가 추적되는 모든 데이터베이스 테이블을 수집함 (상위 테이블).
- config/gitlab_loose_foreign_keys.yml 파일을 읽어서 이를 달성함.
- 테이블은 느슨한 외래 키 정의가 테이블에 존재하고 DELETE 트리거가 설치되어 있는 경우에 “추적되는” 것으로 간주되며, 레코드가 정리된 상태이므로 “추적되는” 것으로 간주됨.
무한 루프로 테이블을 순환함.
각 테이블에 대해 삭제된 상위 레코드의 일괄처리를 로드함.
YAML 구성에 따라 참조 자식 테이블에 대한 DELETE 또는 UPDATE (nullify) 쿼리를 작성함.
쿼리를 호출함.
모든 하위 레코드가 정리되거나 최대 제한에 도달할 때까지 반복함.
모든 하위 레코드가 정리되면 삭제된 상위 레코드를 제거함.

데이터베이스 구조

이 기능은 부모 테이블에 설치된 트리거에 의존합니다. 부모 레코드가 삭제되면, 트리거는 자동으로 loose_foreign_keys_deleted_records 데이터베이스 테이블에 새 레코드를 삽입합니다.

삽입된 레코드에는 삭제된 레코드에 대한 다음과 같은 정보가 저장됩니다:

fully_qualified_table_name: 레코드의 위치한 데이터베이스 테이블의 이름.
primary_key_value: 레코드의 ID, 해당 값은 외래 키 값으로 자식 테이블에 존재합니다. 현재로서는 복합 기본 키는 지원되지 않으며, 부모 테이블은 id 열을 가져야 합니다.
status: 기본값은 대기 중이며, 정리 프로세스의 상태를 나타냅니다.
consume_after: 기본값은 현재 시간입니다.
cleanup_attempts: 기본값은 0입니다. 이 레코드를 정리하려는 워커의 시도 횟수이며, 이 수가 0이 아닌 경우 이 레코드에는 많은 자식 레코드가 있고 클리닝하기 위해서는 몇 번의 실행이 필요합니다.

데이터베이스 분해

데이터베이스 분해 이후 “ci” 및 “main” 데이터베이스 서버에 loose_foreign_keys_deleted_records 테이블이 있습니다. 워커는 lib/gitlab/database/gitlab_schemas.yml YAML 파일을 읽어 어떤 부모 테이블이 어떤 데이터베이스에 속하는지 결정합니다.

예:

Main 데이터베이스 테이블
- projects
- namespaces
- merge_requests
Ci 데이터베이스 테이블
- ci_builds
- ci_pipelines

워커가 “ci” 데이터베이스를 위해 호출될 때, 워커는 ci_builds 및 ci_pipelines 테이블에서만 삭제된 레코드를 로드합니다. 정리 프로세스 중에, DELETE 및 UPDATE 쿼리는 주로 Main 데이터베이스에 있는 테이블에서 실행됩니다. 예를 들어, 여기서 하나의 UPDATE 쿼리는 merge_requests.head_pipeline_id 열을 null로 만듭니다.

데이터베이스 파티셔닝

데이터베이스 테이블이 일일히 많은 양의 삽입을받는다는 이유로 데이터 블로트 문제를 해결하기 위해 특별한 파티션 전략이 구현되었습니다. 원래 time-decay 전략이 이 기능에 대해 고려되었지만, 데이터 양이 너무 많아 새로운 전략을 구현하기로 결정했습니다.

삭제된 레코드는 직접적인 자식 레코드가 모두 정리되면 완전히 처리된 것으로 간주됩니다. 이런 경우, 느슨한 외래 키 워커는 삭제된 레코드의 status 열을 업데이트합니다. 이 단계 이후, 더 이상 레코드는 필요하지 않습니다.

슬라이딩 파티셔닝 전략은 특정 조건이 충족되면 새로운 파티션을 추가하고 이전 파티션을 제거함으로써 오래된 사용되지 않는 데이터를 효율적으로 정리하는 효과적인 방법을 제공합니다. loose_foreign_keys_deleted_records 데이터베이스 테이블은 주로 하나의 파티션이 연결되어 있습니다.

                                                            파티셔닝된 테이블 "public.loose_foreign_keys_deleted_records"
           열            |    형식    | Collation | ᅳ길 |                      기본값                      | 저장  | Stats target | 설명
────────────────────────┼───────────┼──────────┼──────┼─────────────────────────────────────────────────┼──────┼────────────┼──────────────
 id                     | bigint    |            | 필수 | nextval('loose_foreign_keys_deleted_records_id_seq'::regclass) | plain |            |
 partition              | bigint    |            | 필수 | 84                                                  | plain |            |
 primary_key_value      | bigint    |            | 필수 |                                                     | plain |            |
 status                 | smallint  |            | 필수 | 1                                                   | plain |            |
 created_at             | timestamp with time zone |          | 필수 | 현재()                                                | plain |            |
 fully_qualified_table_name | text       |            | 필수 |                                                     | 확장 |            |
 consume_after          | timestamp with time zone |          |        | 현재()                                                | plain |            |
 cleanup_attempts       | smallint  |            |        | 0                                                   | plain |            |
파티셔닝 키: LIST (partition)
Indexes:
    "loose_foreign_keys_deleted_records_pkey" 주요 키, btree (partition, id)
    "index_loose_foreign_keys_deleted_records_for_partitioned_query" btree (partition, fully_qualified_table_name, consume_after, id) WHERE status = 1
CheckConstraints:
    "check_1a541f3235" CHECK (char_length(fully_qualified_table_name) <= 150)
Partitions: gitlab_partitions_dynamic.loose_foreign_keys_deleted_records_84 FOR VALUES IN ('84')

partition 열은 삽입 방향을 제어하며, partition 값은 트리거를 통해 삽입된 삭제된 행이 어느 파티션에 삽입되는지를 결정합니다. partition 테이블의 기본 값이 list partition 값과 일치하는 것에 유의하십시오 (84). 트리거에서의 INSERT 쿼리에서 partition의 값은 생략되며, 트리거는 항상 열의 기본 값에 의존합니다.

트리거에 대한 예를 찾아보십시오:

INSERT INTO loose_foreign_keys_deleted_records
(fully_qualified_table_name, primary_key_value)
SELECT TG_TABLE_SCHEMA || '.' || TG_TABLE_NAME, old_table.id FROM old_table;

파티션이 “슬라이딩” 프로세스는 정기적으로 실행되는 두 개의 콜백에 의해 제어됩니다. 이러한 콜백은 LooseForeignKeys::DeletedRecord 모델 내에서 정의되어 있습니다.

next_partition_if 콜백은 새 파티션을 생성할 때 제어합니다. 현재 파티션에 하나 이상의 레코드가 24시간 이상 있을 때 새 파티션을 생성합니다. PartitionManager를 사용하여 다음 단계로 새 파티션을 추가합니다:

CURRENT_PARTITION + 1을 사용하여 새 파티션 생성
partition 열의 기본값을 CURRENT_PARTITION + 1로 업데이트합니다.

이러한 단계로 인해 모든 새로운 INSERT 쿼리는 새 파티션에 삽입됩니다. 이 시점에서 데이터베이스 테이블에는 두 개의 파

쿼리 정리

LooseForeignKeys::CleanupWorker에는 Arel에 의존하는 데이터베이스 쿼리 빌더가 있습니다. 이 기능은 예상치 못한 부작용을 피하기 위해 애플리케이션별 ActiveRecord 모델을 참조하지 않습니다. 데이터베이스 쿼리는 일괄 처리되며, 이는 여러 개의 상위 레코드가 동시에 정리되는 것을 의미합니다.

삭제 쿼리 예시:

DELETE
FROM "merge_request_metrics"
WHERE ("merge_request_metrics"."id") IN
  (SELECT "merge_request_metrics"."id"
    FROM "merge_request_metrics"
    WHERE "merge_request_metrics"."pipeline_id" IN (1, 2, 10, 20)
    LIMIT 1000 FOR UPDATE SKIP LOCKED)

상위 레코드의 주 키 값은 1, 2, 10, 20입니다.

업데이트(널 값 지정) 쿼리 예시:

UPDATE "merge_requests"
SET "head_pipeline_id" = NULL
WHERE ("merge_requests"."id") IN
    (SELECT "merge_requests"."id"
     FROM "merge_requests"
     WHERE "merge_requests"."head_pipeline_id" IN (3, 4, 30, 40)
     LIMIT 500 FOR UPDATE SKIP LOCKED)

이러한 쿼리는 일괄 처리되어 많은 경우 여러 번의 호출이 필요합니다. 일괄 처리는 루프로 구현되며, 처리가 멈추면 모든 연결된 하위 레코드가 정리되었거나 제한에 도달합니다.

loop do
  modification_count = process_batch_with_skip_locked
  
  break if modification_count == 0 || over_limit?
end

loop do
  modification_count = process_batch
  
  break if modification_count == 0 || over_limit?
end

이 루프 기반의 일괄 처리는 다음과 같은 이유로 EachBatch보다 우선합니다.

일괄 처리된 레코드가 수정되므로 다음 일괄 처리에는 다른 레코드가 포함됩니다.
외래 키 열에 항상 인덱스가 있지만, 해당 열은 일반적으로 고유하지 않습니다. EachBatch는 반복을 위해 고유한 열이 필요합니다.
레코드 순서는 정리에 영향을 주지 않습니다.

2개의 루프가 있다는 점에 주목하세요. 초기 루프는 SKIP LOCKED 절을 사용하여 레코드를 처리합니다. 쿼리는 다른 애플리케이션 프로세스에 의해 잠그린 행을 건너뜁니다. 이를 통해 정리 작업이 차단될 가능성이 줄어듭니다. 두 번째 루프는 데이터베이스 쿼리를 실행할 때 SKIP LOCKED 없이 모든 레코드가 처리되었는지 확인합니다.

처리 제한

상수로 많은 양의 레코드 업데이트 또는 삭제는 사고를 유발하고 GitLab의 가용성에 영향을 줄 수 있습니다.

테이블 과다 확대.
보류 중인 WAL 파일 수 증가.
잠금 획득이 어려운 바쁜 테이블.

이러한 문제를 완화하기 위해 작업이 실행될 때 여러 제한이 적용됩니다.

각 쿼리에는 LIMIT가 있어서 무제한 행 수를 처리할 수 없습니다.
레코드 삭제 및 업데이트의 최대 수가 제한됩니다.
데이터베이스 쿼리에 대한 최대 실행 시간(30초)이 제한됩니다.

이러한 제한 규칙은 LooseForeignKeys::ModificationTracker 클래스에 구현되어 있습니다. 레코드 수정 수 또는 시간 제한 중 하나에 도달하면 즉시 처리가 중지됩니다. 시간이 지난 후 다음 예약된 작업이 정리 프로세스를 계속합니다.

성능 특성

상위 테이블의 데이터베이스 트리거는 레코드 삭제 속도를 내립니다. 상위 테이블의 행을 제거하는 각 문은 트리거를 호출하여 loose_foreign_keys_deleted_records 테이블에 레코드를 삽입합니다.

정리 작업 내의 쿼리는 상당히 효율적인 인덱스 스캔이며, 제한이 있어서 애플리케이션의 다른 부분에 영향을 미치지 않을 확률이 높습니다.

데이터베이스 쿼리는 트랜잭션 내에서 실행되지 않으며, 예를 들어 문 제한 시간이나 직원 충돌이 발생하는 경우, 다음 작업이 처리를 계속합니다.

문제 해결

삭제된 레코드의 축적

작업자가 비정상적으로 많은 데이터를 처리해야 하는 경우가 발생할 수 있습니다. 일반적으로 삭제되었는데 이 상황이 발생할 수 있습니다. 예를 들어 대규모 프로젝트 또는 그룹이 삭제될 때 발생합니다. 이러한 상황에서 수백 만 개의 레코드를 삭제하거나 널 값으로 설정해야 할 수 있습니다. 작업자가 적용하는 제한으로 인해 이러한 데이터 처리는 시간이 걸립니다.

“무거운 레코드”를 정리할 때, 이 기능은 큰 배치를 나중에 다시 예약하여 공정한 처리를 보장합니다. 이렇게 하면 다른 삭제된 레코드를 처리할 시간이 생깁니다.

예를 들어, 수백만 개의 ci_builds 레코드가 있는 프로젝트가 삭제되었습니다. ci_builds 레코드는 느슨한 외래 키 기능에 의해 삭제됩니다.

정리 작업자가 예약되어 삭제된 projects 레코드의 배치를 가져옵니다. 대형 프로젝트가 해당 배치에 포함됩니다.
고아가 된 ci_builds 행의 삭제가 시작됩니다.
시간 제한에 도달했지만 정리가 완료되지 않았습니다.
삭제된 레코드의 “cleanup_attempts” 열이 증가했습니다.
1단계로 이동합니다. 다음 정리 작업자가 정리를 계속합니다.
“cleanup_attempts”가 3에 도달하면 “consume_after” 열을 업데이트하여 10분 후에 배치를 다시 예약합니다.
다음 정리 작업자가 다른 배치를 처리합니다.

삭제된 레코드 클린업을 모니터링하기 위해 프로메테우스 지표가 준비되어 있습니다.

loose_foreign_key_processed_deleted_records: 처리된 삭제된 레코드 수. 대규모 정리가 발생하면 이 숫자는 감소합니다.
loose_foreign_key_incremented_deleted_records: 처리되지 않은 삭제된 레코드 수. “cleanup_attempts” 열이 증가했습니다.
loose_foreign_key_rescheduled_deleted_records: 3회의 정리 시도 후 나중에 다시 예약된 삭제된 레코드 수.

Thanos 쿼리 예시:

loose_foreign_key_rescheduled_deleted_records{env="gprd", table="ci_runners"}

상황을 파악하는 또 다른 방법은 데이터베이스 쿼리를 실행하는 것입니다. 이 쿼리는 처리되지 않은 레코드의 정확한 수를 제공합니다.

SELECT partition, fully_qualified_table_name, count(*)
FROM loose_foreign_keys_deleted_records
WHERE
status = 1
GROUP BY 1, 2;

예시 출력:

 partition | fully_qualified_table_name | count
-----------+----------------------------+-------
        87 | public.ci_builds           |   874
        87 | public.ci_job_artifacts    |  6658
        87 | public.ci_pipelines        |   102
        87 | public.ci_runners          |   111
        87 | public.merge_requests      |   255
        87 | public.namespaces          |    25
        87 | public.projects            |     6

이 쿼리는 팁을 제공하는데 유용합니다. 여러 다른 파티션 값이 디렉터리에 존재하는 경우, 삭제된 레코드의 정리가 며칠 동안 완료되지 않았음을 의미합니다(매일 새로운 파티션이 추가됩니다).

문제 진단 단계:

어떤 레코드가 축적되고 있는지 확인합니다.
남은 레코드의 개수를 추정하려고 합니다.
작업자의 성능 통계(Kibana 또는 Thanos)를 살펴보기.

가능한 해결책:

단기간: 배치 크기를 증가시킵니다.
장기간: 작업자를 더 자주 실행합니다. 작업자를 병렬화합니다.

일회성 해결책으로, 레일스 콘솔에서 정리 작업자를 여러 번 실행할 수 있습니다. 작업자는 병렬로 실행될 수 있지만 이렇게 하면 잠금 경합이 발생할 수 있고 작업자 실행 시간이 늘어날 수 있습니다.

LooseForeignKeys::CleanupWorker.new.perform

정리가 완료되면 이전 파티션은 자동으로 PartitionManager에 의해 분리됩니다.

PartitionManager 버그

이 문제는 이전에 스테이징에서 발생했으며 해결되었습니다.

새로운 파티션을 추가할 때 partition 열의 기본값도 업데이트됩니다. 이것은 같은 트랜잭션에서 실행되는 스키마 변경입니다. partition 값이 오래되어 사용되지 않게 될 가능성은 극히 낮습니다.

그러나 이러한 경우가 발생하면 응용 프로그램 전체적인 사고를 유발할 수 있습니다. 왜냐하면 partition 값이 존재하지 않는 파티션을 가리킬 수 있기 때문입니다. 증상: DELETE 트리거가 설치된 테이블에서 레코드 삭제에 실패합니다.

\d+ loose_foreign_keys_deleted_records;
           
           Column           |           Type           | Collation | Nullable |                            Default                             | Storage  | Stats target | Description
----------------------------+--------------------------+-----------+----------+----------------------------------------------------------------+----------+--------------+-------------
 id                         | bigint                   |           | not null | nextval('loose_foreign_keys_deleted_records_id_seq'::regclass) | plain    |              |
 partition                  | bigint                   |           | not null | 4                                                              | plain    |              |
 primary_key_value          | bigint                   |           | not null |                                                                | plain    |              |
 status                     | smallint                 |           | not null | 1                                                              | plain    |              |
 created_at                 | timestamp with time zone |           | not null | now()                                                          | plain    |              |
 fully_qualified_table_name | text                     |           | not null |                                                                | extended |              |
 consume_after              | timestamp with time zone |           |          | now()                                                          | plain    |              |
 cleanup_attempts           | smallint                 |           |          | 0                                                              | plain    |              |
Partition key: LIST (partition)
Indexes:
    "loose_foreign_keys_deleted_records_pkey" PRIMARY KEY, btree (partition, id)
    "index_loose_foreign_keys_deleted_records_for_partitioned_query" btree (partition, fully_qualified_table_name, consume_after, id) WHERE status = 1
Check constraints:
    "check_1a541f3235" CHECK (char_length(fully_qualified_table_name) <= 150)
Partitions: gitlab_partitions_dynamic.loose_foreign_keys_deleted_records_3 FOR VALUES IN ('3')

partition 열의 기본값을 확인하고 사용 가능한 파티션과 비교합니다(4 대 3). 값이 4인 파티션이 존재하지 않습니다. 이 문제를 완화하기 위해서 비상 스키마 변경이 필요합니다.

ALTER TABLE loose_foreign_keys_deleted_records ALTER COLUMN partition SET DEFAULT 3;

느슨한 외부 키

문제 설명

비동기 접근

작동 방식

`scripts/decomposition/generate-loose-foreign-key`

마이그레이션 및 구성 예제

느슨한 외부 키 구성

레코드 변경 추적

외부 키 제거

느슨한 외부 키 제거

테스트

느슨한 외부 키의 주의사항

레코드 생성

관련 조회

`dependent: :destroy` 및 `dependent: :nullify`에 대한 참고

느슨한 외래 키의 위험 및 가능한 완화 방안

레코드가 삭제되어야 하지만 뷰에 표시됨

삭제된 상위 레코드가 뷰 렌더링에 필요하며 `500` 오류를 유발함

삭제된 상위 레코드가 Sidekiq 워커에서 액세스되어 작업 실패를 유발함

아키텍처

데이터베이스 구조

데이터베이스 분해

데이터베이스 파티셔닝

쿼리 정리

처리 제한

성능 특성

문제 해결

삭제된 레코드의 축적

PartitionManager 버그

도움말

기능 사용 가능성과 제품 평가판

도움받기

느슨한 외부 키

문제 설명

비동기 접근

작동 방식

scripts/decomposition/generate-loose-foreign-key

마이그레이션 및 구성 예제

느슨한 외부 키 구성

레코드 변경 추적

외부 키 제거

느슨한 외부 키 제거

테스트

느슨한 외부 키의 주의사항

레코드 생성

관련 조회

dependent: :destroy 및 dependent: :nullify에 대한 참고

느슨한 외래 키의 위험 및 가능한 완화 방안

레코드가 삭제되어야 하지만 뷰에 표시됨

삭제된 상위 레코드가 뷰 렌더링에 필요하며 500 오류를 유발함

삭제된 상위 레코드가 Sidekiq 워커에서 액세스되어 작업 실패를 유발함

아키텍처

데이터베이스 구조

데이터베이스 분해

데이터베이스 파티셔닝

쿼리 정리

처리 제한

성능 특성

문제 해결

삭제된 레코드의 축적

PartitionManager 버그

도움말

기능 사용 가능성과 제품 평가판

도움받기

`scripts/decomposition/generate-loose-foreign-key`

`dependent: :destroy` 및 `dependent: :nullify`에 대한 참고

삭제된 상위 레코드가 뷰 렌더링에 필요하며 `500` 오류를 유발함