가동 중지 시간없이 프로덕션 코드베이스 / 데이터베이스 스키마를 어떻게 업데이트합니까?

42

다운 타임없이 프로덕션 서버의 코드베이스 / 데이터베이스 스키마를 업데이트하는 몇 가지 기술은 무엇입니까?

deployment

1

많은 사람들이 이것을 간과하기 때문에 좋은 질문입니다. 합법적 인 이유에 관계없이 시간은 돈이며 가동 중지 시간은 최종 사용자에게 좋지 않습니다.

— Dan McGrath

@ Dan McGrath : 실제로 가동 중지 시간이 발생할 수 있다고 가정하면 (일반적으로) 일년에 4 번 (분기 중단) 다운되고 매번 최대 15 분 (트래픽이 대기하는 시간 동안) 인 시스템에서 작동합니다. .. 데이터베이스 변경이 심도있게 조사되었습니다 :)

— Matthieu M.

2

이것은 dba.stackexchange.com 에게 좋은 질문이 될 것 입니다. 몇 시간 안에 공개 베타 버전으로 들어갑니다.

— 래리 콜먼

20

일반적으로 이런 종류의 요구 사항이있는 작업을 수행 한 웹 사이트는 모두 부하 분산 장치 뒤에 있거나 별도의 장애 조치 위치가있었습니다. 이 샘플에서는 단일로드 밸런서, 2 개의 웹 서버 (A & B) 및 2 개의 데이터베이스 서버 (M & N-일반적으로 DB 서버는 최소한 SQL Server 세계에서 로그 쉽핑을 통해 연결됨)가 있다고 가정합니다. ).

웹 서버 A와로드 밸런서의 연결을 끊어야합니다 (따라서 들어오는 모든 트래픽은 B로갑니다).
로그 전달이 중지되었습니다 (DB Server M이 먼저 업데이트됩니다).
웹 서버 A 업데이트
업데이트가 작동했는지 테스트하고 확인하십시오 (보통 사람들이 IP 주소를 직접 치고 있음).
기존 세션이 계속 B로 이동하도록로드 밸런서를 설정하십시오. 새 세션은 A로 이동하십시오.
B의 모든 세션이 만료 될 때까지 기다립니다 (일반적으로 30 분 이상이 될 수 있습니다. 일반적으로 트래픽을보고 1 시간의 휴식 시간이 있습니다).
B와 N을 업데이트하십시오.
업데이트가 작동했는지 테스트하고 확인하십시오.
로그 전달을 다시 설정하고 작동하는지 테스트하십시오.
로드 밸런서를 정상 작동으로 설정하십시오.

매우 복잡한 웹 응용 프로그램에서 1-5 단계로 설명 된 내용은 밤새 걸릴 수 있으며 시간 및 긴급 연락처 번호가 포함 된 50 페이지 Excel 스프레드 시트 일 수 있습니다. 이러한 상황에서는 시스템을 절반 만 업데이트하면 오후 6시에서 오전 6 시로 예약되어 있으며 사용자는 시스템을 사용할 수 있습니다. DR 사이트의 업데이트 처리는 일반적으로 다음 날 밤에 예정되어 있습니다. 첫날에 아무것도 깨지 않기를 바랍니다.

가동 시간이 필요한 경우 QA 환경에서 패치를 먼저 테스트합니다. 이는 프로덕션과 동일한 하드웨어입니다. 중단이 없으면 보통 주말에 정기 일정에 적용 할 수 있습니다.

— 탕구 레나
소스

7

DB M과 DB N의 새로운 데이터 병합을 어떻게 제안합니까? 그들은 다른 사람이 가지고 있지 않은 새롭고 업데이트되고 삭제 된 레코드를 가지고 있습니다.

— sixtyfootersdude

@ Tangurena, 당신은 위의 의견에 대답 할 수 있습니까?

— sino

9

일반적인 데이터베이스 (예 : Oracle)의 경우 쿼리를 병렬로 실행하면서 데이터베이스 스키마를 변경할 수 있습니다. 그래도 약간의 계획이 필요합니다.

변경 사항을 적용하려면 몇 가지 제한 사항이 있습니다.

기존 코드와 함께 작동해야합니다. 즉, 코드는 이전 버전과 새 버전의 스키마를 모두 처리해야합니다.
트랜잭션이 중단 될 수있는 DB에로드가 발생해서는 안됩니다 (나는 당신을보고 있습니다 CREATE INDEX)
데이터 손실이 발생하지 않아야합니다 (테이블을 삭제 및 재 작성할 수 없음).

스키마가 이전 버전과 호환되도록하려면 일반적으로 열을 추가 또는 수정하고 기존 코드에서 더 이상 사용하지 않는 경우에만 무언가를 DROP 할 수 있습니다.

코드가 변경 사항을 투명하게 처리 할 수 없으면 데이터베이스를 변경하기 전에 코드를 변경하십시오.

포워드 계획에 대한 간단한 조언 : 항상 DB 요청에 열 이름을 명시하십시오 (사용하지 마십시오 SELECT * FROM). 이렇게하면 이전 요청에 새 열이 표시되지 않습니다.

— 마티유
소스

1

실제로, 앞으로 계획 및 적응성을 위해 수동으로 열을 나열하는 것보다 * from을 선택하는 것이 훨씬 좋습니다. 명시적인 열 이름을 사용하면 대부분의 경우 많은 기술적 부채가 발생합니다. 코드가 새 열에서 분리되면 코드가 이미 손상된 것입니다.

— Morg.

@ 모건 : 실제로는 아닙니다. 보안을 위해 바인드 변수를 사용해야합니다. 바인드 프레임에서 (적어도) 쓸 변수를 제공해야하며 출력 열만큼 정확하게 변수가 있어야하므로 select *코드가 깨지면 새 열이 추가됩니다 (작성할 변수가없는 경우). 물론 이것은 강력한 형식의 언어를 사용한 결과 일 수 있습니다.

— Matthieu M.

그렇습니다. select *를 피하는 데 추가 보안이 없습니다. 그것은 강하게 타이핑 된 언어와는 아무 관련이 없으며 매우 나쁜 디자인과 관련이 있습니다. 프레임 워크가 변경 사항을 완벽하게 처리 할 수 없으면 쓸모가 없습니다. 열을 변경하면 응용 프로그램이 작동을 멈추지 않습니다. 당신이 할 때 휴식. 어느 것이 더 신뢰할 수 있는지 또는 안전한지에 대해서는 의문이 없다고 생각합니다.

— Morg.

@ 모건 : 나는 어떻게 select *더 신뢰할 수 있고 안전 하지 못합니다 . 예전에는 and select one, two from ...만 사용했습니다 . 경우 테이블에 추가, 당신은 그것을 (여기)에 대한 사용이 없다, 그래서를 검색 할 이유가 없다. 갑자기 코드를 사용해야하는 경우 코드를 수정하므로이 시점에서 쿼리를 수정할 수도 있습니다! onetwothird

— Matthieu M.

@ 모건 : 글쎄, 우리는 서로의 과거 경험이 다르기 때문에 서로 이야기하고있는 것 같습니다. 나는 성능이 가장 중요한 제품인 제품을 연구하고 select있으며, 이는 가능한 한 선택적으로 (그리고 지수로 커버되어야 함) 의미합니다 . 유감스럽게 생각하지만 설명하는 방식은 해당 제품에서 완전히 실패했습니다.

— Matthieu M.

5

모든 시스템을 지원할 수있는 것은 아니지만이를 지원하는 방식으로 설정해야합니다.

예를 들어, 몇 년 전에 업그레이드를 도와 준 주요 시스템 중 하나를 연중 무휴 사용할 수 있어야합니다. 오프 사이트 사용자 인터페이스 계층과 비즈니스 계층 간의 순수한 통신 계층을 포함하여 여러 계층으로 구성되었습니다. 통신 계층의 코딩 방식으로 인해 비즈니스 계층 또는 DB 스키마에 대한 향후 변경 사항은 실제 중단없이 구현 될 수 있습니다. 최악의 시나리오에서는 변경 사항이 적용되어 10-30 초의 일시 중지가 발생합니다.

변경 사항이 순전히 비즈니스 계층에 대한 코드 변경 사항 인 경우 밀리 초 지연으로 대기하고 '사이클 인'할 수 있습니다.

다음과 같은 이유로이 작업을 수행 할 수 있습니다.

통신 계층은 메시지를 보유 할 수 있습니다. 이를 통해 UI를 중단하지 않고도 UI 계층 이외의 계층에서 실제 중단이 발생했습니다.
MVDB에 의해 처리 비즈니스 계층라는 UniData을 . 이것은 모든 코드를 메모리에 보관합니다. 코드를 컴파일 한 후 명령을 사용하여 새 객체 코드를 메모리에 강제로 저장하여 기존 객체를 교체 할 수 있습니다.

다른 기술에는 트랜잭션을 기존 시스템의 다른 미러로 복제하는 것이 포함됩니다. 업데이트를 하나에 적용하여 업데이트와 스위치 사이에서 수행 된 모든 트랜잭션을 전환하고 재생합니다. 그래도 시스템에 따라 YMMV.

— 댄 맥그래스
소스

1

임베디드 데이터베이스 시스템 및 임베디드 시스템과는 다른 관점이 있습니다. 임베디드 시스템에는 다양한 네트워크 / 통신 인프라 장비가 포함되며이 영역에서는 가동 시간이 약 99.999 % (5 9 초)입니다.

당사 (McObject)는 eXtremeDB 고 가용성을 포함하여 eXtremeDB 계열의 내장 데이터베이스 시스템 제품 공급 업체입니다.

먼저 "내장 데이터베이스"는 데이터베이스 시스템이 응용 프로그램 코드와 컴파일되고 링크 된 라이브러리라는 것을 이해하십시오. 그런 의미에서 응용 프로그램에 "포함"됩니다.

eXtremeDB 고 가용성을 사용하면 애플리케이션의 MASTER 인스턴스 (하나 이상의 프로세스 일 수 있음)와 하나 이상의 REPLICA 애플리케이션 인스턴스가 있습니다. 복제본이 마스터에 연결되면 "초기 동기화"라는 프로세스를 통해 마스터 데이터베이스의 복사본을받습니다. 마스터 애플리케이션이 작업을 계속하는 동안 수행 할 수 있습니다. 동기화되면 복제를 통해 마스터의 트랜잭션을 수신합니다. 따라서 복제본은 항상 최신 데이터를 가지고 있으며 마스터가 실패 할 경우 장애 조치라는 프로세스를 통해 인수 할 수 있습니다.

초기 동기화의 한 가지 기능을 "이진 스키마 진화"라고합니다. 일반 영어로, 이는 복제본 데이터베이스를 채우는 프로세스가 복제본의 데이터베이스 스키마와 마스터의 데이터베이스 스키마 간의 차이를 수용한다는 것을 의미합니다.

실제로 이것은 새로운 / 삭제 된 테이블, 새로운 / 삭제 된 / 변경된 필드, 새로운 / 삭제 된 인덱스를 사용하여 최신 버전의 응용 프로그램을 빌드하고 해당 응용 프로그램의 새 버전을 마스터에 첨부 한 후 새 복제본이 새 마스터가되도록합니다 (즉, 새 복제본으로 장애 조치를 강제 실행하여 마스터가되고 이전 마스터가 자체 종료 됨). Voila, 시스템 가용성을 방해하지 않으면 서 애플리케이션을 버전 N에서 N + 1로 마이그레이션했습니다. 이제 이전 마스터 및 기타 복제본을 버전 N + 1로 업그레이드 할 수 있습니다.