다음을 통해 공유


Azure Database for MySQL의 주 버전 업그레이드 - 유연한 서버

적용 대상: Azure Database for MySQL - 유연한 서버

참고 항목

이 문서에는 Microsoft에서 더 이상 사용하지 않는 용어인 슬레이브라는 용어에 대한 참조가 포함되어 있습니다. 소프트웨어에서 용어가 제거되면 이 문서에서 해당 용어가 제거됩니다.

이 문서에서는 Azure Database for MySQL 유연한 서버에서 MySQL 주 버전을 현재 위치로 업그레이드하는 방법을 설명합니다. 이 기능을 통해 고객은 데이터를 이동하거나 애플리케이션 연결 문자열을 변경할 필요 없이 MySQL 5.7 서버를 MySQL 8.0으로 현재 위치 업그레이드할 수 있습니다.

Important

  • 가동 중지 시간 기간은 데이터베이스 인스턴스의 크기와 포함된 테이블 수에 따라 다릅니다.
  • Rest API 또는 SDK를 통해 Azure Database for MySQL 유연한 서버에 대한 주 버전 업그레이드를 시작하는 경우 동일한 요청에서 서비스의 다른 속성을 수정하지 마십시오. 동시 변경은 허용되지 않으며 의도하지 않은 결과 또는 요청 실패로 이어질 수 있습니다. 업그레이드 완료 후 별도의 작업에서 속성 수정을 수행하세요.
  • 일부 워크로드는 5.7에서 8.0으로 업그레이드한 후 성능이 향상되지 않을 수 있습니다. 프로덕션 환경에서 업그레이드를 구현하기 전에 먼저 복제본 서버(테스트 서버)를 만든 다음 독립 실행형 서버로 승격시키고 테스트 서버에서 워크로드를 실행하여 워크로드의 성능을 평가하는 것이 좋습니다.
  • 주 MySQL 버전 업그레이드는 되돌릴 수 없습니다. 유효성 검사에서 서버가 제거되거나 사용되지 않는 기능으로 구성된 것으로 유효성 검사되면 배포가 실패할 수 있습니다. 서버에서 필요한 구성을 변경하고 업그레이드를 다시 시도할 수 있습니다.

필수 조건

  • MySQL 버전 5.7의 읽기 복제본은 다른 MySQL 버전 간에 복제가 호환되도록 하려면 주 서버보다 먼저 업그레이드해야 합니다. 자세한 내용은 MySQL 버전 간 복제 호환성을 참조하세요.
  • 이제 프로덕션 서버를 업그레이드하기 전에 Azure Portal의 기본 제공 유효성 검사 기능을 사용하여 더 쉽고 효율적으로 작업할 수 있습니다. 이 도구는 데이터베이스 스키마와 MySQL 8.0의 호환성을 미리 검사하여 잠재적인 문제를 강조 표시합니다. 이 편리한 옵션을 제공하지만 공식 Oracle MySQL 업그레이드 검사 도구를 사용하여 데이터베이스 스키마 호환성을 테스트하고, 필요한 회귀 테스트를 수행하여 새 MySQL 버전에서 삭제된/사용되지 않는 기능과의 애플리케이션 호환성을 확인하는 것을 적극 권장합니다.

    참고 항목

    Oracle의 공식 도구를 사용하여 스키마 호환성을 확인하는 경우 저장 프로시저에서 예상치 않은 토큰을 나타내는 다음과 같은 몇 가지 경고가 발생할 수 있습니다. mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode 이러한 경고는 무시해도 됩니다. Azure MySQL 기능을 지원하는 데 사용되는 mysql.을 접두사로 하는 기본 제공 저장 프로시저를 참조합니다. 이러한 경고는 데이터베이스의 기능에 영향을 미치지 않습니다.

  • 프로덕션 서버에서 주 버전 업그레이드를 수행하기 전에 주문형 백업을 트리거합니다. 이는 수행된 전체 주문형 백업에서 버전 5.7로 롤백하는 데 사용할 수 있습니다.
  • 주 버전 업그레이드를 진행하기 전에 진행 중인 XA 트랜잭션으로 인해 업그레이드 프로세스가 실패할 수 있으므로 데이터베이스에 활성 또는 보류 중인 XA 트랜잭션이 없는지 확인하세요. 이 문제를 방지하려면 먼저 실행 XA RECOVER;하여 "준비됨" 상태의 XA 트랜잭션을 확인합니다. 식별된 트랜잭션의 경우 ;를 사용하여 XA ROLLBACK '{xid}'각 트랜잭션을 롤백하고 {xid}를 트랜잭션 ID로 바꿉니다. 트랜잭션 일관성을 유지하고 업그레이드 실패 위험을 줄이기 위해 업그레이드를 시작하기 전에 모든 XA 트랜잭션이 커밋되거나 롤백되었는지 확인합니다.

버스트 가능 SKU 서버에 대해 Azure Portal을 사용하여 MySQL 5.7에서 MySQL 8.0으로 계획된 주 버전 업그레이드 수행

Azure Database for MySQL 버스트 가능 SKU 컴퓨팅 계층에 대한 주 버전 업그레이드를 수행하려면 특수 워크플로가 필요합니다. 주 버전 업그레이드는 리소스를 많이 사용하므로 상당한 CPU와 메모리가 요구되기 때문입니다. 크레딧 기반인 버스트 가능 SKU 인스턴스는 이러한 요구 사항에 따라 어려움을 겪을 수 있으며, 이로 인해 업그레이드 프로세스가 실패할 수도 있습니다. 따라서 버스트 가능 SKU를 업그레이드할 때 시스템은 먼저 컴퓨팅 계층을 범용 SKU로 업그레이드하여 업그레이드에 충분한 리소스를 사용할 수 있도록 합니다.

Azure Portal을 사용하여 Azure Database for MySQL 버스트 가능 SKU 컴퓨팅 계층에 대한 주 버전 업그레이드를 수행하려면 다음 단계를 따릅니다.

  1. Azure Portal에서 기존 Azure Database for MySQL 유연한 서버 5.7 서버를 선택합니다.

    Important

    프로덕션을 직접 업그레이드하는 것보다 서버의 복원된 복사본에서 먼저 업그레이드를 수행하는 것이 좋습니다. 지정 시간 복원을 수행하는 방법을 참조하세요.

  2. 개요 페이지의 도구 모음에서 업그레이드를 선택합니다.

    Important

    업그레이드하기 전에 MySQL 8.0에서 삭제된 기능 목록 링크를 방문합니다. 배포 실패를 방지하기 위해 더 이상 사용되지 않는 sql_mode 값을 확인하고, Azure Portal에서 서버 매개 변수 블레이드를 사용하여 현재 Azure Database for MySQL 유연한 서버 5.7 서버에서 해당 값을 제거/선택 취소합니다. 값이 NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS 및 NO_TABLE_OPTIONS인 sql_mode는 MySQL 8.0에서 더 이상 지원되지 않습니다.

    Azure Database for MySQL 유연한 서버 업그레이드를 보여주는 스크린샷.

  3. 스키마 호환성 유효성 검사

    업그레이드를 계속하기 전에 Oracle의 공식 MySQL 업그레이드 확인 도구를 실행하여 현재 데이터베이스 스키마가 MySQL 8.0과 호환되는지 유효성을 검사합니다. 이 단계는 원활한 업그레이드 프로세스를 보장하는 데 중요합니다.

  4. 업그레이드 전 결정

    업그레이드를 계속하기 전에 주 버전 업그레이드를 수행하기 위해 업그레이드할 컴퓨팅 계층을 선택해야 합니다. 기본적으로 시스템은 버스트 가능 SKU에서 가장 기본적인 범용 SKU로 업그레이드하지만, 필요한 경우 더 높은 컴퓨팅 계층으로 업그레이드하도록 선택할 수 있습니다.

    참고 항목

    서버는 업그레이드 중에 "범용" 계층에서 작동하지만 이 기간에 사용된 실제 "범용" 리소스에 대해서만 요금이 청구됩니다.

  5. 업그레이드 후 결정

    업그레이드 후 범용 SKU를 유지할지 또는 버스트 가능한 SKU로 되돌릴지 결정합니다. 초기 업그레이드 단계 중에 이를 선택하라는 메시지가 표시됩니다.

    시스템은 자동으로 컴퓨팅 계층을 버스트 가능 SKU에서 선택한 범용 SKU로 업그레이드하여 주 버전 업그레이드를 지원합니다.

  6. 주 버전 업그레이드

    컴퓨팅 계층이 업그레이드되면 시스템은 주 버전 업그레이드 프로세스를 시작합니다. Azure Portal을 통해 업그레이드 진행률을 모니터링합니다. 업그레이드 프로세스는 데이터베이스의 크기와 작업에 따라 다소 시간이 걸릴 수 있습니다.

    참고 항목

    주 버전 업그레이드가 실패하면 컴퓨팅 계층이 이전 버스트 가능 SKU로 자동으로 되돌아가지 않습니다. 이는 고객이 컴퓨팅 계층 업그레이드를 다시 수행할 필요 없이 주 버전 업그레이드를 계속할 수 있도록 하기 위한 것입니다.

  7. 자동 되돌리기

    업그레이드 전 결정에 따라, 시스템은 업그레이드 완료 후 범용 SKU를 유지하거나 자동으로 버스트 가능 SKU로 되돌아갑니다.

    참고 항목

    버스트 가능 SKU로 자동으로 되돌아가도록 선택한 경우 시스템은 기본적으로 B2S SKU로 되돌아갑니다.

범용 및 중요 비즈니스용 SKU 서버에 대해 Azure Portal을 사용하여 MySQL 5.7에서 MySQL 8.0으로 계획된 주 버전 업그레이드 수행

Azure Portal을 사용하여 Azure Database for MySQL 5.7 유연한 서버 5.7의 주 버전 업그레이드를 수행하려면 다음 단계를 수행합니다.

  1. Azure Portal에서 기존 Azure Database for MySQL 유연한 서버 5.7 서버를 선택합니다.

    Important

    프로덕션을 직접 업그레이드하는 것보다 서버의 복원된 복사본에서 먼저 업그레이드를 수행하는 것이 좋습니다. 지정 시간 복원을 수행하는 방법을 참조하세요.

  2. 개요 페이지의 도구 모음에서 업그레이드를 선택합니다.

    Important

    업그레이드하기 전에 MySQL 8.0에서 삭제된 기능 목록 링크를 방문합니다. 배포 실패를 방지하기 위해 더 이상 사용되지 않는 sql_mode 값을 확인하고, Azure Portal에서 서버 매개 변수 블레이드를 사용하여 현재 Azure Database for MySQL 유연한 서버 5.7 서버에서 해당 값을 제거/선택 취소합니다. 값이 NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS 및 NO_TABLE_OPTIONS인 sql_mode는 MySQL 8.0에서 더 이상 지원되지 않습니다.

    Azure Database for MySQL 유연한 서버 업그레이드를 보여주는 스크린샷.

  3. 업그레이드 전 유효성 검사 수행

    업그레이드를 계속하기 전에 유효성 검사 단추를 클릭하여 MySQL 8.0과 서버의 호환성을 확인합니다.

    유효성 검사를 보여주는 스크린샷.

    Important

    '유효성 검사' 기능을 사용하여 데이터베이스 스키마와 MySQL 8.0의 호환성을 확인하는 경우, 전체 스키마를 정확하게 평가하기 위해 테이블을 잠그는 작업이 포함됩니다. 이 프로세스는 쿼리 시간 초과로 이어질 수 있습니다. 따라서 사용량이 많은 업무 시간 동안 또는 데이터베이스에 트래픽이 많은 경우 유효성 검사를 수행하지 않는 것이 좋습니다. 유효성 검사를 위해 활동이 적은 기간을 선택하면 작업에 미치는 영향을 최소화하는 데 도움이 될 수 있습니다.

  4. 업그레이드 사이드바의 업그레이드할 MySQL 버전 텍스트 상자에서 업그레이드할 주요 MySQL 버전(예: 8.0)을 확인합니다.

    업그레이드를 보여 주는 스크린샷.

    주 서버를 업그레이드하려면 먼저 연결된 모든 읽기 복제본 서버를 업그레이드해야 합니다. 이 작업이 완료될 때까지 업그레이드가 사용하지 않도록 설정됩니다.

  5. 주 서버에서 확인 메시지를 선택하여 모든 복제 서버가 업그레이드되었는지 확인한 다음 업그레이드를 선택합니다.

    업그레이드를 보여 주는 스크린샷.

    읽기 복제본 및 독립 실행형 서버에서 업그레이드는 기본적으로 사용하도록 설정되어 있습니다.

Azure CLI를 사용하여 MySQL 5.7에서 MySQL 8.0으로 계획된 주 버전 업그레이드 수행

Azure CLI를 사용하여 Azure Database for MySQL 5.7 유연한 서버 5.7를 서버의 주 버전 업그레이드를 수행하려면 다음 단계를 수행합니다.

  1. Windows용 Azure CLI를 설치하거나 Azure Cloud Shell에서 Azure CLI를 사용하여 업그레이드 명령을 실행합니다.

    이 업그레이드를 수행하려면 Azure CLI 버전 2.40.0 이상이 필요합니다. Azure Cloud Shell을 사용하는 경우 최신 버전이 이미 설치되어 있습니다. az version을 실행하여 설치된 버전과 종속 라이브러리를 찾습니다. 최신 버전으로 업그레이드하려면 az upgrade를 실행합니다.

  2. 로그인한 후 az mysql server upgrade 명령을 실행합니다.

    az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version 8
    
  3. 확인 프롬프트에서 y를 입력하여 확인하거나 n을 입력하여 업그레이드 프로세스를 중지한 다음 Enter 키를 누릅니다.

Azure Portal을 사용하여 읽기 복제본 서버에서 MySQL 5.7에서 MySQL 8.0으로 주 버전 업그레이드 수행

Azure Portal을 사용하여 읽기 복제본에서 Azure Database for MySQL 유연한 서버 5.7 서버를 MySQL 8.0으로 주 버전 업그레이드를 수행하려면 다음 단계를 수행합니다.

  1. Azure Portal에서 기존 Azure Database for MySQL 유연한 서버 5.7 읽기 복제본 서버를 선택합니다.

  2. 개요 페이지의 도구 모음에서 업그레이드를 선택합니다.

Important

업그레이드하기 전에 MySQL 8.0에서 삭제된 기능 목록 링크를 방문합니다. 배포 실패를 방지하기 위해 더 이상 사용되지 않는 sql_mode 값을 확인하고, Azure Portal에서 서버 매개 변수 블레이드를 사용하여 현재 Azure Database for MySQL 유연한 서버 5.7 서버에서 해당 값을 제거/선택 취소합니다.

  1. 업그레이드 섹션에서 업그레이드를 선택하여 Azure Database for MySQL 유연한 서버 5.7 서버 읽기 복제본 서버를 MySQL 8.0으로 업그레이드합니다.

    업그레이드가 성공했음을 확인시켜 주는 알림이 나타납니다.

  2. 개요 페이지에서 Azure Database for MySQL 유연한 서버 읽기 복제본 서버에서 실행 중인 버전이 8.0인지 확인합니다.

  3. 이제 주 서버로 이동하여 주 버전 업그레이드를 수행합니다.

읽기 복제본을 사용하여 MySQL 5.7에서 MySQL 8.0으로 최소 가동 중지 시간 주 버전 업그레이드 수행

읽기 복제본 서버를 사용하여 가동 중지 시간을 최소화하면서 Azure Database for MySQL 유연한 서버 5.7 서버에서 MySQL 8.0으로 주 버전 업그레이드를 수행하려면 다음 단계를 수행합니다.

  1. Azure Portal에서 기존 Azure Database for MySQL 유연한 서버 5.7 서버를 선택합니다.

  2. 주 서버에서 읽기 복제본을 만듭니다.

  3. 읽기 복제본을 버전 8.0으로 업그레이드합니다.

  4. 복제본 서버가 버전 8.0에서 실행되고 있는지 확인한 후 애플리케이션이 주 서버에 연결하지 못하게 합니다.

  5. 복제 상태를 확인하여 모든 데이터가 동기화되고 기본에서 새 작업이 수행되지 않도록 복제본이 기본을 따라 잡았는지 확인합니다.

  6. 복제 상태를 보려면 복제본 서버에서 show replica status 명령으로 확인합니다.

     SHOW SLAVE STATUS\G
    

    Slave_IO_Running 및 Slave_SQL_Running 상태가 yes이고 Seconds_Behind_Master 값이 0이면 복제가 잘 작동하는 것입니다. Seconds_Behind_Master는 복제본의 지연 시간을 나타냅니다. 값이 0이 아니면 복제본이 계속 업데이트를 처리하고 있는 것입니다. Seconds_Behind_Master 값이 ****인지 확인한 후 복제를 중지해도 안전합니다.

  7. 복제를 중지하여 읽기 복제본을 주 복제본으로 승격합니다.

  8. 서버 매개 변수 read_only를 0(OFF)으로 설정하여 승격된 기본에 쓰기를 시작합니다.

  9. 애플리케이션에서 서버 8.0을 실행하는 새 주 복제본(이전 복제본)을 가리킵니다. 각 서버에는 고유한 연결 문자열이 있습니다. 원본 대신 (이전) 복제본을 가리키도록 애플리케이션을 업데이트합니다.

참고 항목

이 시나리오에서는 4~7단계 동안에만 가동 중지 시간이 발생합니다.

자주 묻는 질문

  • 이로 인해 서버 가동 중지 시간이 발생하나요? 발생한다면 기간은 얼마나 되나요?

    업그레이드 중 가동 중지 시간을 최소화하려면 읽기 복제본을 사용하여 MySQL 5.7에서 MySQL 8.0으로 최소 가동 중지 주 버전 업그레이드 수행에 언급된 단계를 따릅니다. 업그레이드 프로세스 중에 서버를 사용할 수 없으므로 계획된 유지 관리 기간 동안 이 작업을 수행하는 것이 좋습니다. 예상 가동 중지 시간은 데이터베이스 크기, 프로비저닝된 스토리지 크기(프로비저닝된 IOP) 및 데이터베이스의 테이블 수에 따라 달라집니다. 업그레이드 시간은 서버의 테이블 수에 정비례합니다. 서버 환경의 가동 중지 시간을 예측하려면 먼저 복원된 서버 복사본에서 업그레이드를 수행하는 것이 좋습니다.

  • 업그레이드 후 내 백업은 어떻게 되나요?

    주 버전 업그레이드 전에 수행된 모든 백업(자동/주문형)은 복원에 사용될 때 항상 이전 버전(5.7)이 있는 서버로 복원됩니다. 주 버전 업그레이드 후 수행된 모든 백업(자동/주문형)은 업그레이드된 버전(8.0)으로 서버에 복원됩니다. 쉬운 롤백을 위해 주 버전 업그레이드를 수행하기 전에 주문형 백업을 수행하는 것이 좋습니다.

  • 현재 버스트 가능 SKU를 사용하고 있습니다. Microsoft는 향후 이 SKU에 대한 주 버전 업그레이드를 지원할 계획입니까?

    버스트 가능한 SKU는 이 SKU의 성능 제한으로 인해 주 버전 업그레이드를 지원할 수 없습니다.

    Azure Database for MySQL 유연한 서버 인스턴스에서 주 버전 업그레이드를 수행해야 하고 현재 버스트 가능 SKU를 사용하는 경우 한 가지 임시 솔루션은 범용 또는 중요 비즈니스용 SKU로 업그레이드한 다음 버스트 가능한 SKU로 다시 전환하는 것입니다.

    더 높은 SKU로 업그레이드하면 가격 변동이 발생할 수 있으며 배포 비용이 증가할 수 있습니다. 그러나 업그레이드 프로세스에 시간이 오래 걸리지 않을 것으로 예상되므로 추가 비용이 크지는 않을 것입니다.

다음 단계