마이그레이션에서 다운타임 방지하기

GitLab 데이터베이스 마이그레이션 시 다운타임 없이 칼럼 삭제, 이름 변경, 타입 변경, 인덱스 추가 등 다양한 작업을 안전하게 수행하는 방법을 설명합니다.

데이터베이스를 다루다 보면 일부 작업은 다운타임을 필요로 할 수 있습니다. 마이그레이션에서 다운타임을 허용할 수 없으므로, 다운타임 없이 동일한 결과를 얻기 위한 일련의 단계를 사용해야 합니다. 이 가이드는 다운타임이 필요할 것처럼 보이는 다양한 작업, 그 영향, 그리고 다운타임 없이 수행하는 방법을 설명합니다. 칼럼 삭제하기 # 칼럼을 제거하는 것은 까다롭습니다. 실행 중인 GitLab 프로세스는 해당 칼럼이 존재한다고 가정하기 때문입니다. ActiveRecord는 칼럼이 참조되지 않더라도 부팅 시 테이블 스키마를 캐시합니다. 이는 칼럼이 명시적으로 무시(ignore) 처리되지 않은 경우 발생합니다. 또한, 해당 칼럼을 참조하는 데이터베이스 뷰도 고려해야 합니다. 이를 안전하게 해결하려면 세 번의 릴리즈에 걸쳐 세 단계를 수행해야 합니다: 칼럼 무시하기 (릴리즈 M) 칼럼 삭제하기 (릴리즈 M+1) 무시 규칙 제거하기 (릴리즈 M+2) 세 번의 릴리즈에 걸쳐 분산시키는 이유는 칼럼 삭제가 쉽게 롤백할 수 없는 파괴적인 작업이기 때문입니다. 이 절차를 따르면 GitLab.com 배포 및 GitLab Self-Managed 인스턴스의 업그레이드 과정에서 이 단계들이 한꺼번에 묶이지 않도록 보장할 수 있습니다. 칼럼 무시하기 (릴리즈 M) # 첫 번째 단계는 애플리케이션 코드에서 칼럼을 무시 처리하고 모델 유효성 검사를 포함하여 해당 칼럼에 대한 모든 코드 참조를 제거하는 것입니다. 이 단계가 필요한 이유는 Rails가 칼럼을 캐시하고 다양한 곳에서 이 캐시를 재사용하기 때문입니다. 무시할 칼럼을 정의하는 방식으로 이 작업을 수행할 수 있습니다. 예를 들어, 릴리즈 12.5 에서 User 모델의 updated_at 을 무시하려면 다음을 사용합니다: class User < ApplicationRecord ignore_column :updated_at, remove_with: '12.7', remove_after: '2019-12-22' end 여러 칼럼을 동시에 무시할 수도 있습니다: ignore_columns %i[updated_at created_at], remove_with: '12.7', remove_after: '2019-12-22' 모델이 CE와 EE에 모두 존재하는 경우, 칼럼은 CE 모델에서 무시 처리해야 합니다. 모델이 EE에만 존재하는 경우에는 EE에 추가해야 합니다. 칼럼 무시 규칙을 언제 제거해도 안전한지 다음과 같이 표시해야 합니다: remove_with : 칼럼 무시를 추가한 후 보통 두 릴리즈(M+2) 뒤의 GitLab 릴리즈로 설정합니다(예시에서는 12.7 ). remove_after : 칼럼 무시를 제거해도 안전하다고 판단하는 날짜로 설정합니다. 일반적으로 M+1 릴리즈 날짜 이후, M+2 개발 사이클 중에 해당합니다. 예를 들어, 12.7 의 개발 사이클이 2019-12-18 ~ 2020-01-17 사이이고, 12.6 이 칼럼을 삭제하는 릴리즈라면, 12.6 의 릴리즈 날짜인 2019-12-22 로 날