큰 데이터베이스에서 잘못된 데이터 업데이트를 피하기 위해 따라야하는 방법은 무엇입니까?

프로덕션 배포 전의 일반적인 조언은 먼저 DB를 백업하는 것입니다. 이런 식으로 새 업데이트에 잠재적 인 데이터 손실 또는 논리적 데이터 손상을 초래할 수있는 문제가있는 경우 여전히 이전 레코드를 비교하고 수정하기위한 백업이 있습니다.

그러나 이것은 DB 크기가 몇 GB가 될 때까지 잘 작동 할 수 있습니다. DB 크기가 크면 백업을 완료하는 데 시간이 오래 걸립니다. 코드 배포시 논리적 문제로 인한 논리적 데이터 손상을 피하기 위해 이러한 상황에서 따라야 할 모범 사례는 무엇입니까?

소프트웨어 업그레이드를 위해 고객의 프로덕션 데이터베이스 업데이트를 정기적으로 처리 한 사람으로서 오류를 최소화하는 가장 좋은 방법은 업데이트를 가능한 한 간단하게하는 것입니다.

특정 레코드가 아닌 모든 레코드를 변경할 수 있으면 바람직합니다.

다시 말해, 상태를 변경해야하는 레코드 ID 목록이 제공되는 경우 프로그램 컨텍스트에서 업데이트가 수행되는 이유를 스스로에게 문의해야합니다. 업데이트해야 할 10 개의 레코드 중 하나 일 수 있으며 테이블 에는 10 개의 요소 만 있습니다 . 따라서 개념적으로 수행하는 모든 작업이 모든 레코드의 상태를 업데이트하는 것인지 스스로에게 문의해야합니다.

삽입 할 수 있으면 바람직합니다.

레코드를 추가하는 행위는 독립적입니다. 이 말은 레코드를 추가 할 때 부작용이 하나뿐이라는 것을 의미하며, 이전에는 존재하지 않았던 레코드가 존재합니다. 따라서 존재하지 않아야 할 레코드를 추가하지 않으면 문제가 없어야합니다.

삭제를 피할 수 있으면 바람직합니다.

삭제를 수행하는 경우 백업 없이는 복구 할 수없는 데이터를 제거하는 것입니다. 가능하면 레코드를 실제로 삭제하지 않고 상태를 변경하여 레코드를 비활성화 할 수있는 방식으로 데이터를 구성하십시오. 초과 된 데이터는 파티션에 넣거나 나중에 문제가없는 것으로 확인되면 나중에 완전히 제거 할 수 있습니다.

일관된 업데이트 정책이 있어야합니다.

레코드를 업데이트해야하는 경우 다음 중 하나가 발생할 수 있습니다.

1. 귀하의 기록이 없습니다.
2. 귀하의 기록이 있지만 이미 변경되었습니다.
3. 귀하의 기록이 존재하며 변경이 필요합니다.

계획된대로 진행되지 않을 경우 조치 과정을 결정하는 정책이 필요합니다. 간단히하기 위해, 전체 테이블에서 일관성을 유지 하고 특정 테이블뿐만 아니라 이러한 유형의 모든 상황 에서이 정책을 적용해야합니다 . 이렇게하면 나중에 데이터를 더 쉽게 복구 할 수 있습니다. 일반적으로 내 정책은 나중에 다시 실행할 수있는 방식으로 스크립트를 작성하는 것입니다. 스크립트가 실패하면 적절한 조정 및 재실행이 가능하지만 자신에게 가장 적합한 정책을 자유롭게 선택할 수 있습니다.

백업

프로덕션 환경에서 업데이트를 수행하기 전에 백업을 수행하는 것을 막을 수는 없습니다. 백업이 있더라도 백업을 사용하지 않아도된다고 생각합니다. 최악의 시나리오 에서도 데이터 손실이 가능하지 않습니다 .

결론

당신은 항상 당신이 그것을 할 수있는 것은 아닙니다. 테이블 스키마는 사용자가 결정할 가능성이 없으므로 수행 할 것으로 예상되는 업데이트 유형이 복잡하고 위험 할 수 있습니다. 문제에 대해 말이 있으면 업데이트를 간단하고 큰 위험없이 수행 할 때 이러한 사항을 명심해야합니다.

행운을 빕니다!

이 시점에서 스냅 샷 을 지원하는 상용 급 DB 시스템 (Oracles는 Flashback이라고 함 )을 사용해야합니다.

어쨌든 백업 개념이 필요하다는 것을 명심하십시오. 더 많은 데이터가 있다고해서 백업이 어려워지기 때문에 백업을 삭제한다는 의미는 아닙니다. 예를 들어 자동 장애 조치 (failover)를 통한 복제 기반의 지속적인 백업이 필요합니다.

이것은 거대한 영역 이므로이 질문은 상당히 짧은 순서로 닫힐 것이지만 내 머리 꼭대기에서 (yuge 데이터베이스의 이전 DBA로) 기대하십시오.

마트 / 리포지토리

업데이트를위한 별도의 데이터베이스와 모든 사람이 사용하는 별도의 데이터베이스가 있으면 약간의 위험을 줄일 수 있습니다. 그런 다음 다양한 검사가 수행되면 한 DB에서 다른 DB로 데이터를 복사하는 경우입니다. 마트 / 리포지토리는 때때로 설명되는 방식이지만 1 차 / 2 차, 마스터 / 슬레이브 등이있을 수 있습니다.

소스 코드

변경할 수있는 모든 것을 위해 , 데이터가 어떻게 업데이트 되었는지 와 관련된 소스 코드가 있어야합니다 . 이 중 몇 개가 DB마다 다르지만 각 사용자, 역할, 데이터 피드, 코드 모듈 등에 하나씩있을 수 있습니다.

작성 / 업데이트 날짜

문제가 발생한 위치를 추적 할 때 크게 도움이되는 것은 모든 행에 대해 데이터를 작성하고 업데이트하는 것입니다. 그러면 업데이트 된 행을 한눈에 볼 수 있습니다.

ETL

데이터베이스 업데이트가 데이터 팩터 리의 일부로 참여하는 경우 플랫 파일에서 이전 빈티지를 복원 할 수 있습니다.

지원

전체 백업은 물론 많은 공간을 차지하지만 일반적인 시나리오는 전체 백업이 규칙적인 간격 (예 : 매주)으로 수행되고 부분 백업은 더 자주 (매일 등) 발생하는 것입니다.

특정 시점 복구

사용중인 RDBMS에 따라 일부 시점 복구가 지원됩니다. 이를 통해 양호한 상태가 알려진 시간으로 롤백 할 수 있습니다. 그러나이를 위해서는 많은 양의 스토리지가 필요합니다.

심사

감사 테이블이 있으면 누가 행을 갱신했는지 누가 알 수 있습니다. 이를 통해 조사를 시작할 수 있습니다.

역사

일부 중요 테이블의 경우 업데이트시 관련 행의 사본이 작성되므로 필요한 경우 데이터를 복원 할 수 있습니다.

데이터 유효성 검사

데이터가 저장되기 전에 기본 데이터 유형 검사 이상으로 기본 유효성 검사가 수행되는지 확인하십시오.

참조 무결성

참조 무결성은 은색 총알이 아니지만 데이터가 잘 구성되어 있는지 확인하는 데 도움이 될 수 있습니다.

"원샷"업데이트를 수행하는 경우 여러 번 프로덕션을 백업하고 테스트 서버로 복원합니다. 그런 다음 테스트를 만들고 원샷을 실행합니다. 우리는 테스트를 통해 데이터가 변경되었는지 확인하고 업데이트가 성공할 것으로 예상하고 데이터를 예상 한대로 수정합니다. 이것을 건식 또는 시운전이라고합니다. 나는 이것을하는 것이 좋습니다.

이를 통해 모든 사람이 원샷을 성공할 수 있습니다. 시험 실행 날짜로부터 데이터가 업데이트되므로 100 % 보장 할 수 없지만 신뢰와 성공 요인은 향상됩니다. 또한 프로덕션 사본을 사용하는 동안 발생할 수있는 모든 문제에 대한 실질적인 정보를 제공합니다. 어떤 이유로 든 업데이트가 실패하면 필요한 경우 복원하기 전에 항상 백런으로 이동할 수 있지만 드라 이런 관련 문제를 찾아서 해결해야합니다.

전체 데이터베이스를 가져올 수없는 경우 (실제로 큰 경우) 더 작은 샘플 크기를 내보내고 실제 데이터에 대해 업데이트 (작은 드라이 런)를 실행하십시오. 가능한 한 테스트가 완료되도록 전체 데이터 세트를 선호합니다.