19.5.3 Upgrading or Downgrading a Replication Topology

19.5.3 Upgrading or Downgrading a Replication Topology

Replication 토폴로지에 참여하는 서버를 업그레이드할 때는 토폴로지에서 각 서버의 역할을 고려해야 하며, 복제에 특화된 이슈를 주의해야 합니다. MySQL Server 인스턴스를 업그레이드하는 일반적인 정보와 절차는 Chapter 3, Upgrading MySQL을 참조하십시오.

Section 19.5.2, “Replication Compatibility Between MySQL Versions”에서 설명한 것처럼, MySQL은 Section 1.3, “MySQL Releases: Innovation and LTS” 및 Section 3.2, “Upgrade Paths”에 설명된 대로 소스 버전에서 레플리카 버전으로 업그레이드를 지원하는 버전 조합에 대해서, 더 오래된 소스에서 더 새로운 레플리카로의 복제를 지원합니다.

그러나 더 나중 릴리스를 실행하는 소스에서 더 이전 릴리스를 실행하는 레플리카로의 복제는 지원하지 않습니다. 더 이전 릴리스의 레플리카는 더 나중 릴리스의 소스가 처리할 수 있는 트랜잭션을 처리하는 데 필요한 기능을 갖추지 못했을 수 있습니다.

따라서 복제 토폴로지의 모든 레플리카를 대상 MySQL Server 릴리스로 업그레이드한 후에야 소스 서버를 대상 릴리스로 업그레이드해야 합니다. 이렇게 하면 더 이전 릴리스에 남아 있는 레플리카가 더 나중 릴리스의 소스로부터 오는 트랜잭션을 처리하려고 시도하는 상황이 발생하지 않습니다.

다중 소스(multi-source replication)가 있는 복제 토폴로지에서는, 소스나 레플리카 MySQL 서버의 수와 관계없이 두 개를 초과하는 MySQL Server 버전의 사용은 지원되지 않습니다. 예를 들어, 이러한 설정에서 MySQL X.Y.1, MySQL X.Y.2, MySQL X.Y.3을 동시에 사용할 수는 없지만, 이들 릴리스 중 어느 두 개라도 함께 사용할 수는 있습니다.

Pre-Check Servers before Upgrade

아직 업그레이드되지 않은 더 이전 릴리스의 소스에서, 이미 업그레이드된 더 나중 릴리스의 레플리카로 복제를 수행할 때 복제 문제를 겪을 수 있습니다. 이는 소스가, 레플리카에 설치된 더 나중 릴리스에서 더 이상 지원되지 않는 구문을 사용하거나 동작에 의존하는 경우 발생할 수 있습니다.

MySQL Shell 업그레이드 검사 유틸리티 util.checkForServerUpgrade()를 사용하여 MySQL 8.0 서버 인스턴스가 MySQL 8.4 릴리스로 업그레이드 가능한지 확인할 수 있습니다. 이 유틸리티는 나중 릴리스에서 더 이상 사용 가능한 기능 및 동작을 포함하여, 업그레이드 문제를 유발할 수 있는 것으로 알려진 설정 및 저장된 데이터를 식별합니다. 업그레이드 검사 유틸리티에 대한 정보는 Upgrade Checker Utility를 참조하십시오.

Standard Upgrade Procedure

복제 토폴로지를 업그레이드하려면, 각 MySQL Server 인스턴스에 대해 Chapter 3, Upgrading MySQL의 지침을 따르되, 다음과 같은 전체 절차를 사용하십시오:

1. 먼저 레플리카를 업그레이드합니다. 각 레플리카 인스턴스에서:

   • Section 3.6, “Preparing Your Installation for Upgrade”에 설명된 사전 검사 및 단계를 수행합니다.

   • MySQL Server를 셧다운합니다.

   • MySQL Server 바이너리 또는 패키지를 업그레이드합니다.

   • MySQL Server를 다시 시작합니다.

   • MySQL Server는 업그레이드 중에 바이너리 로깅을 비활성화하고 전체 MySQL 업그레이드 절차를 자동으로 수행합니다.

   • START REPLICA를 사용하여 복제를 다시 시작합니다.

2. 레플리카의 계층이 여러 개(replica-of-replica)가 있는 경우, 소스에서 가장 먼 레플리카부터 업그레이드를 시작하여, bottom-up 방식으로 업그레이드를 수행합니다.

3. 모든 레플리카가 업그레이드되고 소스만 남았을 때, 레플리카 중 하나로 스위치오버를 수행합니다. 즉, 소스에서 클라이언트 업데이트를 중지하고, 적어도 한 레플리카가 모든 변경 사항을 적용할 때까지 기다렸다가, 해당 레플리카가 소스가 되고 기존 소스는 복제 토폴로지 밖에 남도록 복제 토폴로지를 재구성합니다. 그런 다음, 단일 서버에 대한 절차에 따라 기존 소스를 업그레이드하고, 이후 토폴로지에 다시 삽입합니다.

복제 토폴로지에서 서버를 다운그레이드해야 하는 경우, 레플리카를 다운그레이드하기 전에 소스를 먼저 다운그레이드해야 합니다. 레플리카에서는 바이너리 로그와 릴레이 로그가 완전히 처리되었는지 확인하고, 다운그레이드를 진행하기 전에 이를 퍼지해야 합니다.

Rolling Downgrade Procedure

1. 업데이트를 중지합니다.

2. 레플리카가 모든 업데이트를 수신할 때까지 기다립니다. 모든 변경 사항을 적용할 때까지 기다릴 필요는 없습니다. 변경 사항을 모두 적용하지 않았다면, 수신한 트랜잭션을 백그라운드에서 처리할 수 있도록 어플라이어를 실행 상태로 유지합니다.

3. 단일 서버 다운그레이드 지침을 따라 소스 서버를 다운그레이드합니다.

4. 다운그레이드된 소스 서버를 토폴로지에 다시 삽입합니다.

5. 업데이트를 다시 허용합니다.

6. 모든 레플리카가 이전 프라이머리로부터 남아 있는 트랜잭션을 모두 적용할 때까지 기다립니다.

7. 각 레플리카에 대해, 레플리카를 토폴로지에서 제거하고, 모든 릴레이 로그를 적용할 때까지 기다린 다음, 단일 서버 다운그레이드 지침에 따라 다운그레이드하고, 토폴로지에 다시 삽입합니다. 레플리카의 계층이 여러 개(replica-of-replica)인 경우, 소스 서버에 가장 가까운 레플리카부터 시작하여 top-down 방식으로 다운그레이드를 수행합니다.