다음을 통해 공유

  • 아티클

강제 서비스(데이터 손실 가능)

데이터베이스 미러링은 미러 서버를 웜 대기 서버로 사용할 수 있는 강제 서비스(데이터 손실 가능)를 재해 복구 방법으로 제공합니다. 미러링 세션에서 주 서버가 미러 서버와 연결이 끊긴 경우에만 서비스를 강제 적용할 수 있습니다. 서비스를 강제 적용하면 데이터가 손실될 수 있으므로 반드시 필요한 경우에만 주의해서 사용해야 합니다.

강제 서비스 지원은 세션의 운영 모드와 상태에 따라 다음과 같이 달라집니다.

  • 일반적으로 성능 우선 모드에서는 주 서버의 연결이 끊어질 때마다 강제 서비스 적용을 지원합니다. 그러나 필요한 것은 아니지만 성능 우선 모드 세션에 미러링 모니터 서버가 있을 수 있습니다. 이 경우 서비스를 강제 적용하려면 미리 서버와 미러링 모니터 서버가 서로 연결되어 있어야 합니다.

  • 자동 장애 조치(Failover) 없는 보호 우선 모드에서는 주 서버의 연결이 끊어질 때마다 강제 서비스 적용을 지원합니다.

  • 자동 장애 조치 있는 보호 우선 모드에서는 미러 서버가 마지막으로 주 서버에 연결되었을 때 미러 데이터베이스를 롤백하지 않은 경우 미러 서버와 미러링 모니터 서버가 서로 연결되어 있고 모두 주 서버에 연결되어 있지 않을 때마다 강제 서비스 적용을 지원합니다.

데이터 손실을 감수하더라도 즉시 데이터베이스 서비스를 복원해야 하는 경우에만 서비스를 강제 적용하는 것이 좋습니다. 서비스를 강제 적용할 경우 미러링이 재개될 때 데이터베이스를 다시 동기화하기가 쉽다는 점을 제외하고 미러링을 제거하는 것과 같은 효과가 있으며 데이터가 손실될 수 있습니다. 서비스를 강제 적용하면 주 역할을 미러 데이터베이스로 원활하게 전환하는 작업이 시작됩니다. 미러 서버는 주 서버의 역할을 맡으며 클라이언트에 즉시 데이터베이스 복사본을 제공합니다. 새로운 주 데이터베이스는 미러 없이 노출된 상태로 실행됩니다.

중요 정보중요

주 서버가 단순히 데이터베이스 미러링 세션과 연결이 끊어졌지만 여전히 실행되고 있으면 일부 클라이언트가 계속해서 원래 주 데이터베이스에 액세스할 수 있습니다. 서비스를 강제 적용하기 전에 클라이언트가 원래 주 서버에 액세스하지 않도록 하는 것이 중요합니다. 그렇지 않으면 서비스가 강제 적용된 후 원래 주 데이터베이스와 현재 주 데이터베이스가 서로 독립적으로 업데이트될 수 있습니다.

강제 서비스의 일반적인 사례

다음 그림에서는 강제 서비스(데이터 손실 가능)의 일반적인 사례를 보여 줍니다.

데이터가 손실될 수 있는 강제 서비스

그림에서 원래 주 서버 Partner_A가 미러 서버 Partner_B에서 사용할 수 없게 되어 미러 데이터베이스의 연결이 끊깁니다. 클라이언트에서 Partner_A를 사용할 수 없는지 확인한 후 데이터베이스 관리자가 Partner_B에 서비스를 강제로 적용하며, 이 경우 데이터가 손실될 수 있습니다. Partner_B가 주 서버가 되고 데이터베이스가 노출된 상태(즉, 미러되지 않은 상태)로 실행됩니다. 이때 클라이언트는 Partner_B에 다시 연결할 수 있습니다.

Partner_A를 사용할 수 있게 되면 새로운 주 서버에 다시 연결하여 세션에 다시 참여하고 미러 역할을 담당합니다. 미러링 세션이 새 미러 데이터베이스를 동기화하지 않고 즉시 일시 중단됩니다. 세션이 일시 중단되면 데이터베이스 관리자가 세션을 재개할지 또는 극단적인 경우 미러링을 제거하고 이전 주 데이터베이스에서 데이터를 복원할지 결정할 수 있습니다. 여기서는 데이터베이스 관리자가 미러링을 재개하도록 선택합니다. 이때 Partner_A는 미러 서버의 역할을 맡고 이전 주 데이터베이스를 성공적으로 동기화된 마지막 트랜잭션 시점까지 롤백합니다. 서비스가 강제 적용되기 전에 미러 서버의 디스크에 기록되지 않은 커밋된 트랜잭션은 손실됩니다. 그런 다음 Partner_A는 이전 미러 서버가 새로운 주 서버가 된 이후의 변경 내용을 새로운 주 데이터베이스에 적용하여 새 미러 데이터베이스를 롤포워드합니다.

[!참고]

성능 우선 모드에서는 미러링 모니터 서버가 필요하지 않지만 미러링 모니터 서버가 구성된 경우 현재 미러 서버에 연결되어 있어야만 서비스를 강제 적용할 수 있습니다.

서비스 강제 적용 시의 위험

서비스를 강제 적용하면 데이터가 손실될 수 있음을 이해하는 것이 중요합니다. 데이터 손실은 미러 서버가 주 서버와 통신할 수 없어 두 데이터베이스의 동기화를 보장할 수 없기 때문에 발생합니다. 서비스를 강제 적용하면 새 복구 분기가 시작됩니다. 원래 주 데이터베이스와 미러 데이터베이스는 서로 다른 복구 분기에 있기 때문에 현재 각 데이터베이스는 다른 데이터베이스에 없는 데이터를 포함합니다. 즉, 원래 주 데이터베이스는 Send Queue에서 이전 미러 데이터베이스로 전송되지 않은 변경 내용(보내지 않은 로그)을 포함하고 이전 미러 데이터베이스는 서비스가 강제 적용된 후 발생한 변경 내용을 포함합니다.

[!참고]

복구 분기 지점에 대한 자세한 내용은 복구 경로을 참조하십시오.

주 서버가 실패하여 서비스가 강제 적용된 경우 발생 가능한 데이터 손실은 실패 전에 미러 서버로 보내지 않은 트랜잭션 로그가 있는지 여부에 따라 달라집니다. 보호 우선 모드에서는 미러 데이터베이스가 동기화될 때까지만 보내지 않은 로그가 있을 수 있습니다. 성능 우선 모드에서는 보내지 않은 로그가 항상 누적되어 있을 수 있습니다.

강제 서비스 적용의 의미는 부분적으로 세션에 미러링 모니터 서버가 있는지 여부에 따라 달라집니다.

  • 미러링 모니터 서버가 없을 경우 네트워크 연결이 끊기는 등의 이유로 파트너의 연결이 끊어지면 서비스를 강제 적용할 수 있습니다. 원래 주 서버가 여전히 실행되고 있으면 두 파트너가 모두 주 역할을 소유합니다. 새로운 주 서버에 연결하는 클라이언트는 현재 버전의 데이터베이스에 액세스하고 원래 주 서버에 연결하는 클라이언트는 원래 주 데이터베이스에 액세스합니다. 이 경우 데이터 손실 가능성이 커집니다. 파트너가 다시 연결할 수 있으면 원래 주 서버는 미러 역할을 맡고 미러링이 일시 중단되기 전에 데이터베이스 상태를 "복구 중"으로 변경합니다. 세션이 재개되면 가장 최근에 연결이 끊어질 때 해당 로그가 Send Queue에 있었던 원래 주 데이터베이스의 트랜잭션이 손실됩니다. 서비스가 강제 적용된 후에 발생한 모든 트랜잭션도 손실됩니다.

  • 미러링 모니터 서버가 있을 경우 미러 서버가 주 서버 및 미러링 모니터 서버와 모두 연결이 끊어지면 주 서버가 노출된 상태로 실행됩니다. 단, 주 서버와 미러링 모니터 서버는 서로 연결되어 있어야 합니다. 그런 다음 주 서버가 미러링 모니터 서버와 연결이 끊어지면 데이터베이스 제공을 중지합니다. 이후에 미러 서버가 미러링 모니터 서버에 다시 연결하면 서비스를 강제 적용할 수 있습니다. 서비스가 강제 적용된 경우 원래 주 서버가 다시 연결하면 원래 주 서버가 노출된 상태로 실행되는 동안 수행된 모든 변경 내용이 손실됩니다.

자세한 내용은 이 항목의 뒷부분에 나오는 "잠재적 데이터 손실 관리"를 참조하십시오.

잠재적 데이터 손실 관리

서비스가 강제 적용된 후 이전 주 서버를 사용할 수 있게 되면 데이터베이스가 손상되지 않았다고 가정할 경우 잠재적 데이터 손실을 관리할 수 있습니다. 잠재적 데이터 손실을 관리하는 데 사용 가능한 방법은 원래 주 서버가 파트너에 다시 연결하여 미러링 세션에 다시 참여했는지 여부에 따라 달라집니다. 원래 주 서버가 새로운 주 인스턴스에 액세스할 수 있다고 가정하면 자동으로 투명하게 다시 연결할 수 있습니다.

원래 주 서버가 다시 연결된 경우

일반적으로 실패 후에 원래 주 서버가 다시 시작되면 신속하게 해당 파트너에 다시 연결합니다. 다시 연결할 때 원래 주 서버는 미러 서버가 됩니다. 해당 데이터베이스는 미러 데이터베이스가 되고 세션이 일시 중단되기 전에 복구 상태가 됩니다. 미러링을 재개하지 않으면 미러 데이터베이스는 롤백되지 않습니다.

그러나 복구 중인 데이터베이스에 액세스할 수 없으므로 데이터베이스를 검사하여 미러링을 재개할 때 손실될 데이터를 평가할 수 없습니다. 따라서 데이터 손실을 감수할지 여부에 따라 미러링을 재개할지 또는 제거할지 결정합니다.

  • 데이터 손실이 허용되지 않는 경우 미러링을 제거하여 데이터를 복원해야 합니다.

    미러링을 제거하면 데이터베이스 관리자가 원래 주 데이터베이스를 복구하여 손실되었을 데이터를 복구할 수 있습니다. 그러나 이전 미러 데이터베이스가 온라인 상태가 되면 이전 파트너가 동일한 이름으로 다른 데이터베이스를 제공합니다. 데이터베이스 관리자는 데이터베이스 중 하나를 클라이언트에서 액세스할 수 없도록 만들어 데이터베이스가 더 이상 달라지지 않도록 하고 클라이언트 장애 조치 문제를 방지해야 합니다.

  • 데이터 손실이 허용되는 경우 미러링을 재개할 수 있습니다.

    미러링을 재개하면 데이터베이스 동기화의 첫 번째 단계로 새 미러 데이터베이스가 롤백됩니다. 실패 시 Send Queue에서 대기 중인 로그 레코드가 있으면 커밋된 경우에도 해당 트랜잭션이 손실됩니다.

원래 주 서버가 다시 연결되지 않은 경우

원래 주 서버가 네트워크를 통해 새로운 주 서버에 다시 연결하지 않도록 일시적으로 차단할 수 있는 경우 원래 주 데이터베이스를 검사하여 미러링을 재개하면 손실될 데이터를 평가할 수 있습니다.

  • 잠재적 데이터 손실이 허용되는 경우

    원래 주 서버가 해당 파트너에 다시 연결할 수 있도록 합니다. 다시 연결하면 미러링이 일시 중단됩니다. 미러링을 계속하려면 세션을 재개하면 됩니다. 이전 주 서버가 미러 역할을 맡습니다. 새 미러 서버는 원래 복구 분기를 삭제하므로 이전 미러 서버로 보내거나 받지 않은 모든 트랜잭션이 손실됩니다.

  • 데이터 손실이 허용되지 않는 경우

    세션을 재개할 때 손실되는 중요한 데이터가 원래 주 데이터베이스에 포함되어 있으면 미러링을 제거하여 원래 주 서버의 데이터를 유지할 수 있습니다. 이때 주 서버의 비상 로그를 백업하는 것이 좋습니다. 그러면 원래 주 데이터베이스에서 유지하려는 데이터를 내보낸 후 현재 주 데이터베이스로 가져와서 현재 주 데이터베이스(이전 미러 데이터베이스)를 업데이트할 수 있습니다. 업데이트된 데이터베이스의 전체 데이터베이스 백업을 가능한 한 빨리 수행하는 것이 좋습니다.

    업데이트된 데이터베이스를 초기 주 데이터베이스로 사용하여 미러링을 다시 설정하려면 이 백업과 하나 이상의 후속 로그 백업을 사용하여 새 미러 데이터베이스를 만듭니다. 미러링이 제거된 후에 수행된 모든 로그 백업을 적용해야 합니다. 따라서 새 미러링 세션이 시작될 때까지 주 데이터베이스의 추가 로그 백업을 지연하는 것이 좋습니다.