몇 마디만 해주세요. 실제로 이 솔루션은 주로 비용 문제를 먼저 고려해야 합니다. 다른 기술적인 문제는 실제로 해결하기 쉽지만 엔터프라이즈 애플리케이션에서는 가장 큰 제한 사항이 비용입니다. ORACLE 데이터베이스를 예로 들어 간략하게 설명하겠습니다. 도움이 되길 바랍니다. (데이터베이스 유형은 중요하지 않으며 솔루션은 모두 유사합니다.)
1. 스토리지 레이어 기반 재해 복구 복제 솔루션
이 기술의 복제 메커니즘은 SAN 기반을 통해 이루어집니다. 스토리지 LAN은 복제에 사용되며 각 IO에 대해 복제가 수행되며 복사되는 데이터의 양이 상대적으로 큽니다. 시스템은 동기식 또는 비동기식의 두 가지 방법으로 데이터 복제를 실현할 수 있습니다. 대용량 데이터(일일 로그 볼륨 60G 이상)가 있는 시스템에 큰 장점이 있지만 호스트, 운영 체제, 데이터베이스 버전 등에 대한 요구 사항이 일관되고 네트워크 환경에 대한 요구 사항이 상대적으로 높습니다.
2. 논리 볼륨 기반 재해 복구 복제 솔루션
이 기술의 메커니즘은 TCP/IP 기반의 네트워크 환경을 통해 복제하고 운영 체제 프로세스가 변경 사항을 캡처하는 것입니다. 논리 볼륨에 복사본을 만듭니다. 그 특성은 저장 장치 기반 복제 솔루션과 유사하며 동기식 또는 비동기식 방법을 선택할 수도 있으며 호스트 소프트웨어 및 하드웨어 환경의 일관성에 대한 요구 사항이 상대적으로 높으며 대용량 응용 프로그램에 더 유리합니다. 데이터. 대상 시스템을 읽을 수 있으려면 타사 이미지를 생성해야 합니다. 개인적으로는 위에서 언급한 이 기술과 스토리지 기반 복제 기술이 데이터 양이 매우 많은 시스템이나 응용 시스템의 재해 복구 복제에 더 적합하다고 생각합니다.
3. oracle redo log 기반의 논리적 복제 방식
이 방식은 주로 일부 타사 소프트웨어와 Oracle 자체 DATAGUARD의 논리적 Standby에서 사용됩니다. 현재 해외에는 상대적으로 성숙한 제품과 성공 사례가 많고, 중국에도 유사한 제품이 있지만, 해외와 비교하면 제품의 성숙도와 성공 사례 사이에는 여전히 일정한 격차가 있습니다.
Oracle이 아닌 독립적인 프로세스를 이용하여 Redo 로그 파일 정보를 캡쳐하고 이를 SQL문으로 변환한 후 네트워크를 통해 타겟 데이터베이스로 전송하고, 타겟 데이터베이스에서도 동일한 SQL을 실행한다. 해당 프로세스가 Oracle 로그 전환을 따라갈 수 없는 경우 아카이브 로그의 내용을 캡처할 수도 있습니다. 트랜잭션을 소스단에서 단위로 사용하는 제품도 있습니다. 트랜잭션이 완료되면 대상단으로 전송됩니다. 모든 제품은 일반적으로 테이블별로 복제하며 대부분의 DDL 복제도 지원합니다(주로 oracle9i 환경에서).
데이터베이스의 처리량이 너무 크면 실제 데이터에 큰 지연이 발생합니다. 데이터베이스의 일일 볼륨이 60G 이상에 도달하면 이 솔루션의 구현 가능성이 달라집니다. 데이터 동기화 및 구성 활성화를 위해 약간의 다운타임이 있을 수 있습니다. 복제 환경이 구축된 후에는 규정된 운영 절차에 따라 데이터베이스 구조에 대한 일부 수정이 수행되어야 하며, 이로 인해 일정한 유지 관리 비용이 발생합니다.