데이터베이스를 지속적으로 배포 할 수있는 사례 또는 도구는 무엇입니까?

데이터베이스 및 특히 RDBMS에 대해 동일한 접근 방식을 사용하는 것과 비교하여 인프라 및 코드의 지속적인 제공 또는 지속적인 배치는 비교적 간단합니다. 배포가 완료된 후에는 코드와 인프라가 변경되거나 발전하지 않습니다. 그러나 데이터베이스에는 스키마 고유의 변경 가능한 구성 요소가 아닌 경우 데이터를 만드는 새로운 데이터가 추가됩니다.

나는 데이터베이스 객체를 추가하는 것, 즉 테이블과 열을 추가하거나 수정하거나 제거하지 않는 것과 같은 관행이 있다는 것을 알고 있습니다-데이터베이스 스키마에 접근하는 순수하게 추가되는 방법은 스키마가 연속적으로 더 복잡한 비용으로 하위 호환성을 보장한다는 이점이 있습니다 스키마.

Flyway 및 Ready Roll 과 같은 제품도 스키마 버전간에 마이그레이션을 작성하는 데 도움이됩니다.

데이터 무결성이 중요한 프로덕션 환경에 데이터베이스 스키마를 지속적으로 배포하기 위해 현재 어떤 다른 관행과 도구가 있습니까?

Pramod Sadalage와 Scott Ambler는 CD org / team에서 DB 주제에 대한 믿을 수 없을 정도로 입문서 인 Refactoring Databases : Evolutionary Database Design 책을 썼습니다 .

도전 과제

데이터베이스 개체 (예 : 테이블 및 열만 추가, 수정 또는 제거 안 함)와 같은 사례가 있음을 알고 있습니다.

내가 일한 한 회사에서, 약 6 개월에 해당하는 원시 데이터 롤링 창이 10TB를 차지했습니다. 그런 다음 데이터는 약 10 년의보고 가능한 데이터를 설명하는 6TB의 사용 가능한 데이터가 필요한 RDBMS 형식으로 처리되었습니다. 요컨대 이러한 종류의 관행은 규모에 관계없이 단순히 실용적이지 않다는 것입니다. 스토리지는 비쌉니다-아마도 가장 큰 컴퓨팅 비용입니다. 이것은 몇 가지 흥미로운 과제를 제공합니다.

1. 백업 -innodb 플러그인은 훌륭하지만 모든 데이터의 백업 시간은 실용적이지 않습니다.
2. 복원 시간 -대용량 데이터 세트의 경우, 특히 복원이 작동 상태로 돌아온 후 며칠 또는 몇 주가 걸릴 수있는 복제를 따라야하는 경우
3. 새 인스턴스 생성 / 시드 -개발 / 테스트에서 수행하는 작업은 종종 데이터 집합의 ETL (추출, 변환 및로드) 작업과 관련이 있습니다. 이는 QA 테스트 단위를 사용하여 유효성을 검증해야하지만 원래 생산 데이터 세트가 보존되도록 비파괴 방식으로 수행해야합니다. 재난이 발생하는 동안 백업이 보험 정책이며이를 피하려는 의도로 이해하기 위해 오랜 복원 시간을 기꺼이 감수해야 할 수도 있습니다. DevOps 개발 워크 플로우에서는 기본적으로 복원 또는 정기적으로 데이터 사본 (아마 하루에 여러 번)
4. 용량 -방금 설명한 규모로 많은 양의 데이터를 처리하는 것은 I / O 집약적 일 수 있습니다. 1-3에 설명 된 문제를 해결해야 할뿐만 아니라 운영 시스템의 중단이나 성능 저하를 유발하지 않는 방식으로 해결해야합니다.

위의 고려 사항은 더 작은 규모, 큰 규모에서는 문제가되지 않을 수 있지만 큰 문제가됩니다. 이는 요구 사항을 정의하고 데이터 집합의 크기를 예측하는 것이 매우 중요 하다는 것을 의미합니다 .

요구 사항 정의

결과적으로 몇 가지 요구 사항을 정의해야합니다.

1. RTO -RTO 또는 백업 시간 복원 목표는 데이터베이스 백업 솔루션의 가장 중요한 드라이버 중 하나입니다. 처음에는 대부분의 다른 문제와 관련이없는 것처럼 보일 수 있지만 "새 인스턴스를 만들거나 시드하기 위해 백업 솔루션을 사용하면 어떻게됩니까?" 다음 섹션에서이를 수행하는 몇 가지 기술을 다룰 것이다.
2. RPO- 백업의 RPO 또는 복원 지점 목표는 A) 복원 할 수있는 거리 (분, 시간, 일, 주, 월 또는 년) B) 다른 계층의 백업 간격 및 C) 세부적으로 복원 할 수있는 방법을 정의합니다. . 예를 들어 전자 메일 데이터베이스의 경우 특정 전자 메일을 복원하는 메시지 수준 백업이 종종 필요합니다. 마찬가지로, 며칠 동안의 데이터는 완전히 쓸모가 없다는 것을 알 수 있습니다. 따라서 1 년을 되 돌리는 포인트는 없습니다.
3. 데이터 세트 크기 -1MB 데이터베이스의 경우 대부분의 백업 제품 및 솔루션으로 RTO를 달성 할 수 있으므로 중요합니다. 그러나 10TB 데이터베이스의 경우, LTO 3 테이프 전체, 행 레벨의 백업이 있음을 발견 할 것이다 아마 당신의 RTO를 달성하지 않으며 백업은 백업 윈도우를 초과 시작하기 때문에 당신의 RPO를 방해 할 수 있습니다. 이 대규모 데이터 세트에서 mysqldump를 정확하게 수행 할 수는 없지만 1MB 데이터베이스에서 mysqldump를 벗어날 수 있습니다.
4. 데이터베이스 일관성 - 데이터베이스 배포 작업시 지속적인 배포, 사이트 안정성, 확장 성 및 가용성이 크게 달라지는 마지막 사항은 일관성에 대한 필요성 (또는 부족)입니다. 즉각적 일관성, JIT (Just-In-Time) 일관성 및 최종 일관성의 세 가지 기본 유형이 있습니다.

위의 주요 고려 사항 외에도 라이센싱 및 지원 요구 사항 (오픈 소스 또는 비공개 소스, 사내 지원, 타사 지원 또는 공급 업체 지원) 응용 프로그램 / 언어 요구 사항 (많은 데이터베이스의 커넥터가 중요 할 수 있음)도 고려해야합니다. 응용 프로그램 컴파일, 소스 코드에 액세스 할 수 있습니까, 다시 컴파일 할 수 있습니까, 아니면 공급 업체에서 제공합니까, 아니면 해석 된 언어로 실행합니까?) 정치적 요구 사항 (조직이 Oracle 만 신뢰합니까? 오라클을 싫어합니까? MySql을 신뢰하지 않습니까? MariaDB 또는 Postgres에 대해 어떻게 생각하십니까?) 데이터베이스 엔진 (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?)과 기록 또는 호환성 요구 사항 (우리는 몇 년 반 동안 PL / SQL을 사용했습니다) 오라클 엔진에 내장되어 있습니다! 어떻게 MariaDB로 포팅 할 수 있습니까?!?)

이 모든 것들이 (주로) 사용 가능한 도구에 영향을 미칩니다.

사내 데이터 관리를위한 일부 옵션

참고 : 다음은 완전한 것이 아니며 다른 SE 사용자는 추가 제안 사항을 알려야합니다.

일반적인 고려 사항을 벗어나서 위의 문제를 해결하기위한 몇 가지 기술과 기술을 제공하겠습니다. 당신이 정말로 경우 먼저 자신에게 물어 필요 RDBMS와를 사용하거나 하둡, CouchDB를 또는 객체 지향 저장 (SWIFT 같은)과 같은 비정형 데이터가 옵션 인 경우.

둘째, 클라우드 기반 솔루션을 살펴보십시오. 이것은이 두통의 일부를 아웃소싱하고 복잡한 문제를 자격을 갖춘 (유료) 개인에게 맡깁니다. 그러나 규모가 크면 예산에 실제로 영향을 미친다는 것을 알 수 있습니다 (클라우드 제공 업체는이를 통해 수익을 창출하고 특정 규모에서는 전문가를 직접 고용 할 수 있습니다). 또는 특정 보안 또는 정치 하에서 작업하는 경우 요구 사항 (읽기 : 클라우드를 수행 할 수 없음)은 하이브리드 NFS / FibreChannel Filer를 고려하십시오. NetApp, Pure Storage 및 Tegile과 같은 대부분의 파일러는 A) 백업 수행, B) 백업 복원 및 C) 새 백업 시드에 매우 유용한 델타 기반 스냅 샷 및 복제 기술을 지원합니다.

이 시점에서 저는 백업 및 스토리지 전문가가 아니므로이 문제의 일부가 다른 문제 (및 녹색 목초지)로 넘어 가기 전에는 해결할 수 없었던 부분이 있습니다.

그러나 이러한 제품을 사용하면 데이터베이스 아래에서 차등 스냅 샷을 만들 수 있습니다. 데이터베이스 인스턴스 중 하나 (읽기 전용 슬레이브가 권장 됨)에서 전체 "읽기 잠금이있는 잠금 테이블"을 스크립팅하고 binlog 위치 또는 GTID를 덤프해야하지만 이러한 파일러의 경우 한 번 수행 할 수 있습니다. 이 스냅을 사용하여 데이터베이스의 새 인스턴스를 만듭니다. binlog를 별도의 파티션에두고 데이터베이스 데이터 만이 파티션에두기를 원할 것입니다. 일단 이러한 파티션을 복제 할 수 있습니다 (NetApp에서는 " FlexClone "이라고 함).

이는 각 블록 읽기에 대해 파일러가 데이터가 고정 된 원래 스냅 샷 또는 델타에 있는지 판별해야하기 때문입니다. 스냅 샷이 여러 개인 볼륨 / 스토어의 경우 여러 번 확인해야 할 수 있습니다. 데이터를 새로 고치거나 (스냅 샷을 버리고 정기적으로 다시 복제하는 것이 좋습니다. 좋은 연속 배포 환경에서 자연스럽고 유기적으로 발생할 수 있음) 또는 볼륨을 영구적으로 분할 (NetApp 용어에서 "Flex Split"이라고 함) )를 사용하면 델타를 영구적으로 해결하고 완전히 새롭고 별도의 볼륨을 만들 수 있습니다.

이러한 델타 클론은 전반적인 스토리지 요구 사항을 줄이는 이점이 있습니다. 여러 클론 또는 프로덕션 데이터베이스 데이터 인스턴스를 생성하여 개발, 테스트 및 검증을 수행 할 수 있습니다. 큰 데이터 세트의 사본 하나에 작은 델타를 더한 상태로 유지하는 경우 전체 스토리지 비용과 설치 공간이 줄어 듭니다.

여기서 유일한 트릭은 "백업"이 여전히 파일러에 있으므로 전체 백업 솔루션을 구성하지 못할 수 있다는 것입니다. 이를 위해 파일러와 데이터 센터간에 데이터를 동기화하는 (rsync 스타일 기술을 사용하는) SnapApp이라고하는 SnapApp 또는 델타 스냅 샷 중 하나를 테이프로 백업 할 수있는 통합 백업 솔루션을 사용해야합니다. 플렉스 클론.

그러나 여기에는 하나의 큰 결함이 있습니다. 모든 데이터-개발자, 테스트 및 제품은 여전히 동일한 파일러 및 스토리지 헤드에서 I / O를 사용하고 있습니다. 이 문제를 해결하려면 테스트 및 / 또는 개발자 파일러의 시드 지점이 될 수있는 두 번째 파일러에서 슬레이브 데이터베이스 인스턴스를 생성하거나 애플리케이션 계층에로드 밸런서 / 애플리케이션 전달 컨트롤러를 사용하여 프로덕션 요청을 미러하십시오. 테스트 및 / 또는 개발 환경. 이는 즉시 눈에 띄지 않을 수있는 문제에 대해 프로덕션으로 승격하기 전에 QA / 테스트 환경에서 발생하는 트래픽을 발생시키는 이점이 있습니다. 그런 다음 프로덕션 트래픽 및 사용자 동작에 따라 로그에서 오류를 확인할 수 있습니다.

그러면 몇 가지 스크립트를 사용하여 연속 배포 방법과 함께 사용하기 위해 전체 (대용량) 데이터 집합을 프로그래밍 방식으로 생성하고 제거 할 수 있습니다.

확장 성 및 고 가용성

지속적인 배포에 대한 질문을했지만 DevOps는 단순한 연속 배포 이상의 문제에 집중되어 있으므로 중복성, 확장 성 및 고 가용성에 대한 몇 가지 내용을 포함하겠습니다.

나는 JIT, 즉각적이고 최종적인 일관성을 언급했습니다. 여기서는 다양한 RDBMS 엔진이 등장합니다. 순환 비동기 복제를 구성하기 만하면 최종 일관성이 비교적 쉽습니다. 그러나 일부 충돌이 발생할 수 있습니다. * (응용 프로그램 계층이 복제가 완료되기 전에 클러스터의 한 쪽과 클러스터의 다른 쪽에서 데이터를 업데이트하는 경우 어떻게됩니까?) 즉각적인 일관성을 유지하려면 동기 복제를 수행하는 Galera 클러스터를 확인하십시오. 확장 성 문제 발생 (네트워크 계층에서 진행 지연으로 인해 대기 시간이 크게 발생하지 않으면 서 어떻게 재해 복구 사이트에 복제하거나 지리적으로로드 균형을 조정합니까?) 또한 데이터 센터 내에서 동기 복제를 수행하고 사이트 간 비동기 복제를 수행 할 수 있는지, 그러나 이것은 두 세계에서 최악의 것 같습니다.

그러나 일반적으로 대부분의 사람들은 완전 동기식 복제가 필요하지 않습니다. 이는 일반적 으로 테이블 샤딩에 다중 마스터가 필요한 매우 구체적인 (고 이국적인) 고 기록 환경에만 필요합니다. 대부분의 앱은 데이터베이스 프록시를 사용하여 Just-In-Time 일관성을 처리 할 수 ​​있습니다. 예를 들어 ScaleArc 는 복제 상태를 모니터링하고 쓰기가 진행된 위치를 추적하여 (복제가 잡힐 때까지 후속 읽기 요청을 보내기 위해) 정시 일관성 및 모양을 제공합니다.데이터베이스 일관성. ScaleArc는 Postgres, MySQL, MariaDB, Oracle 및 MSSQL과 호환되며, 정규식을 사용하여 샤드 키를 사용할 수없는 애플리케이션을 위해 데이터베이스를 샤딩 / 파티션 할 수 있습니다. 또한 구성 관리 소프트웨어와 상호 작용할 수있는 강력한 REST API가 있으며 지원 팀이 뛰어납니다

마찬가지로 MariaDB 팀이 MariaDB를 위해 개발 한 무료 대안 인 MaxScale 을 고려할 수도 있습니다 . 그러나 GUI와 ScaleArc의 일부 캐싱 기능이 부족합니다.

마지막으로, MySQL 패브릭 (및 RAM이 많은 RAM을 감당할 수있는 경우에만 RAM 내 MySQL 클러스터)은 특히 MySQL의 새로운 프록시를 사용하는 다른 가능성이 있습니다. 이는 환경에 확장 성 및 중복성 구성 요소를 제공 할 수 있습니다.

Postgres와 Oracle에는 필요한 복제 및 샤딩 기능이 있어야하지만 프록시가 필요한 경우 ScaleArc가 제대로 페어링됩니다.

궁극적으로 클라우드 기반 환경을 사용할 수없고 클라우드 공급자가 위의 문제를 처리하게 할 수없는 경우 이러한 모든 요소는 지속적인 배포 및 개발에 적합한 매우 유연한 환경에 추가됩니다.

Flyway 를 사용 하여 앱에서 Postgres 스키마 를 관리 하고 Pillar 는 Cassandra 스키마를 관리합니다. 앱이 자체 스키마를 관리하는 것이 가장 좋습니다.

앱이 자체 스키마를 관리하기 전에 관리 스키마를 관리하는 데 끔찍한 경험이 있었습니다 .

스키마 책임을 응용 프로그램 팀으로 옮기지 않으면 도구만으로는 도움이되지 않는다고 주장합니다.

우리는 사용 할 liquibase 또는 이동 경로를 응용 프로그램 팀이 변경 집합을 만들 책임이 작품에서.

이와 함께 순전히 부가적인 방법을 피할 수 있습니다.
각 응용 프로그램은 이전 버전과 호환되어야하며 스키마를 변경해야하는 경우 응용 프로그램은 스키마에 새 열을 통합하고,이를 기록한 후 여전히 이전 열에서 읽고 쓸 수 있습니다 ( 이전 버전은 여전히 ​​동일한 데이터를 갖습니다).
다음 버전의 응용 프로그램은 이전 열의 업데이트를 중지 할 수 있으며 세 번째 버전 만 사용되지 않는 열을 제거 할 수 있습니다.

문제가 생길 경우 정기적 인 백업이 필요합니다.
프로덕션에서 이러한 문제를 피하기 위해 통합 테스트에서 문제를 일으킬 가능성이있는 적절한 데이터 하위 집합도 좋습니다. 이상적인 경우는 생산 데이터의 익명 하위 집합을 얻습니다.

우리는 직장 에서 liquibase 를 사용 하고 그것에 대해 높게 말할 것입니다. 또한 QA 도구 인 QASymphony 에서도 사용됩니다 .

우리는 내부적으로 MSSQL 및 Oracle 데이터베이스에 대해 그것을 사용하고 있으며 QASymphony는 postgres + mysql 인스턴스와 함께 사용했습니다.

메인 프레임 환경 및 DB2® 데이터베이스와 관련하여이 질문에 대답하기 위해 일반적으로 다음 두 가지 중에서 선택할 수있는 두 가지 (일반적으로 저렴하지 않은) 대안이 있습니다.

• BMC의 DB2® 에 대한 오브젝트 관리 . 다음은 링크 된 페이지에서 인용 한 내용입니다.

  데이터베이스의 객체를 변경하거나 심지어 일상적인 관리 작업을 수행하는 것은 어렵고 위험한 작업 일 수 있습니다. 추적해야 할 수십 가지 작업이 있으며 한 번의 실수만으로도 가용성과 데이터 무결성에 심각한 영향을 줄 수 있습니다. 다음을 지원하는 도구 모음 인 BMC Object Administration for DB2 11을 사용하면 노력과 위험을 줄일 수 있습니다.

  • 복잡하고 다른 DB2 환경을 관리하는 데 필요한 시간을 줄입니다.
  • 무결성 향상을 위해 응용 프로그램 수명주기 동안 일상적인 작업을 자동화합니다.
  • 단순화 된 DB2 카탈로그 탐색 및 변경 관리로 생산성을 향상시킵니다.
  • 최소한의 중단으로 변경 및 유지 관리를 수행하여 응용 프로그램 가용성을 향상시킵니다.

• IBM의 z / OS 용 DB2 관리 도구

  가용성에 미치는 영향을 최소화하면서 애플리케이션 라이프 사이클 전체에서 DB2 오브젝트 및 스키마를 안전하게 관리하는 것과 관련된 복잡한 작업을 단순화합니다.

  • 사용자가 DB2 카탈로그를 빠르고 쉽게 탐색 할 수 있습니다.
  • 정확한 SQL 구문을 몰라도 동적 SQL 문을 빌드하고 실행합니다.
  • 실행 전에 잠재적 충돌을 해결하여 DB2 오브젝트 정의에 대한 변경 사항을 관리하고 추적합니다.
  • 데이터베이스 및 테이블에 대해 실행할 DB2 명령 작성을 도와줍니다.
  • 사용자가 DB2 오브젝트를 작성, 변경, 마이그레이션, 삭제 및 리버스 엔지니어링 할 수 있습니다.
  • 유틸리티 작업을 빌드하고 실행하여 사용자가 생산성 향상을 위해 LISTDEF 및 TEMPLATE를 활용할 수 있습니다

SCM 도구와 통합

얼마 전 저는 고객이 SCM 수명주기 ( SERENA ChangeMan ZMF에서 관리)에서 BMC 대안을 실제로 "통합"해야한다는 문제를 겪었습니다 . 이러한 통합의 기본 개념은 " DB2 DBA 팀 (DDL과 함께 작업)을 개발 팀의 특수 사례로 생각하고, 우연히 이국적인 편집기 (BMC 도구)를 사용하여 마이그레이션 할 코드 (DDL)를 생성하는 것 "이라고 생각합니다.

이 통합에 대한 유일한 (그러나 실제 !) 도전에 대한 정보는 "재시작 가능성"을 촉진하는 것이 었습니다. 이는 "DBA 도구의 주요 이점 중 하나입니다.

• 재시작 가능성 은이 DBA 도구가 완료 될 작업의 특성에 따라 때때로 오래 실행되는 작업을 통해 해당 작업을 수행 할 때 예기치 않은 상황 (교착 상태, 시간 이상 종료 등)이 발생할 수 있음을 의미합니다.

• 이러한 상황이 발생하고 백업을 시작하기 전에 (시작하기 전에) 원하지 않는 경우 DBA 도구는 문제가 시작된 지점 (및 위치)에서 다시 시작해야합니다. 모든 것이 다시 실행되기를 원합니다).

• DBA 도구에 대한 새로운 꿀벌이 그러한 체크 포인트에서 다시 시작하는 방법을 실제로 알지 못하고 단순히 처음부터 다시 시도하면 DBA 도구는 단순히 실패합니다. 일종의 사용자 오류가 있습니다. 그리고 이것은 " 마지막으로 실패한 후 어떻게 진행하길 원하는지 말해 줄 때까지, (일을 더 악화시키지 않기 위해) 아무것도하지 않겠다 "는 표시가 있습니다.

• 결국, 사용중인 SCM 도구에서 이러한 재시작 가능성을 구현할 수있는 실마리는 SCM 도구도 조정해야했습니다. 실제로 실패한 SCM 프로 시저 를 다시 시작하는 데 사용할 수 있도록 허용 (일반적으로 대상 테스트 / 프로덕트 환경으로의 전송과 관련됨) ... 실패한 SCM 프로 시저를 다시 제출하는 대신 (일반적으로 이러한 상황에서 SCM 도구가 복구되는 방식) ).

보너스 : BMC 대안의 SCM 통합이 완료된 후 고객은 DBA 도구를 IBM 대안으로 변경하기로 결정했습니다. 두 대안이 모두 동일하게 보이지는 않지만 SCM 통합에 미치는 영향은 미미합니다. 단순히 재사용 가능한 SCM 사용자 정의에서 일부 IBM 호출을 대신하여 BMC 대안에 대한 호출을 대체하는 문제입니다. 대안 ... (DevOps 용어 사용) feature-flags / feature-toggles에 의해 구현되었습니다 .