읽기 복제본 구성

이 페이지에서는 읽기 복제본을 관리하는 방법을 설명합니다. 이러한 작업에는 복제 중지 및 사용 설정, 복제본 승격, 병렬 복제 구성, 복제 상태 확인이 포함됩니다.

복제 작동 방식에 대한 자세한 내용은 Cloud SQL의 복제를 참조하세요.

복제 사용 중지

기본적으로 복제본은 복제가 사용 설정된 상태에서 시작합니다. 그러나 인스턴스 상태를 디버그하거나 분석하는 등의 경우에 복제 사용을 중지할 수 있습니다. 준비가 되면 복제를 다시 사용하도록 명시적으로 설정합니다. 복제를 사용 중지하거나 다시 사용 설정해도 복제 인스턴스는 다시 시작되지 않습니다.

복제를 사용 중지하면 복제 인스턴스는 중지되지 않고 읽기 전용 인스턴스가 되어 더 이상 기본 인스턴스에서 복제하지 않습니다. 인스턴스에 대한 요금은 계속 청구됩니다. 사용 중지된 복제본에서 다시 복제를 사용 설정하거나 복제본을 삭제하거나 독립형 인스턴스로 승격할 수 있습니다.

복제 사용 중지 방법

콘솔

  1. Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

    Cloud SQL 인스턴스로 이동

  2. 복제본 인스턴스의 이름을 클릭하여 선택합니다.
  3. 버튼 모음에서 복제 사용 중지를 클릭합니다.
  4. 확인을 클릭합니다.

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

명령줄 프롬프트에서 이 cURL 명령어를 실행하려면 gcloud auth print-access-token 명령어를 사용하여 액세스 토큰을 획득해야 합니다. Instances:patch 페이지의 API 탐색기를 사용하여 REST API 요청을 보낼 수도 있습니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

  • project-id: 프로젝트 ID
  • replica-name: 복제본 인스턴스의 이름

HTTP 메서드 및 URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

JSON 요청 본문:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

다음과 비슷한 JSON 응답이 표시됩니다.

REST v1beta4

명령줄 프롬프트에서 이 cURL 명령어를 실행하려면 gcloud auth print-access-token 명령어를 사용하여 액세스 토큰을 획득해야 합니다. Instances:patch 페이지의 API 탐색기를 사용하여 REST API 요청을 보낼 수도 있습니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

  • project-id: 프로젝트 ID
  • replica-name: 복제본 인스턴스의 이름

HTTP 메서드 및 URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON 요청 본문:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

다음과 비슷한 JSON 응답이 표시됩니다.

복제 사용 설정

복제본이 오랜 시간 동안 복제되지 않은 경우 기본 인스턴스를 복제하는 데 더 오래 걸릴 수 있습니다. 이 경우 해당 복제본을 삭제하고 새 복제본을 만듭니다.

복제를 사용 설정하려면 다음 안내를 따르세요.

콘솔

  1. Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

    Cloud SQL 인스턴스로 이동

  2. 복제본 인스턴스의 이름을 클릭하여 선택합니다.
  3. 복제 사용 설정을 클릭합니다.
  4. 확인을 클릭합니다.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

명령줄 프롬프트에서 이 cURL 명령어를 실행하려면 gcloud auth print-access-token 명령어를 사용하여 액세스 토큰을 획득해야 합니다. Instances:patch 페이지의 API 탐색기를 사용하여 REST API 요청을 보낼 수도 있습니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

  • project-id: 프로젝트 ID
  • replica-name: 복제본 인스턴스의 이름

HTTP 메서드 및 URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

JSON 요청 본문:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

다음과 비슷한 JSON 응답이 표시됩니다.

REST v1beta4

명령줄 프롬프트에서 이 cURL 명령어를 실행하려면 gcloud auth print-access-token 명령어를 사용하여 액세스 토큰을 획득해야 합니다. Instances:patch 페이지의 API 탐색기를 사용하여 REST API 요청을 보낼 수도 있습니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

  • project-id: 프로젝트 ID
  • replica-name: 복제본 인스턴스의 이름

HTTP 메서드 및 URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON 요청 본문:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

다음과 비슷한 JSON 응답이 표시됩니다.

복제본 승격

읽기 복제본을 승격하면 복제가 중지되고 인스턴스가 읽기 및 쓰기 기능을 포함한 독립형 Cloud SQL 기본 인스턴스로 변환됩니다.

승격될 때 읽기 복제본은 자동으로 백업으로 구성되지만 고가용성(HA) 인스턴스로 자동 구성되지는 않습니다. 복제본이 아닌 인스턴스와 마찬가지로 복제본을 승격한 후에 고가용성을 사용 설정할 수 있습니다. 고가용성을 위해 읽기 복제본을 구성하는 작업은 기본 인스턴스와 동일한 방식으로 수행됩니다. 고가용성을 위한 인스턴스 구성 자세히 알아보기

읽기 복제본을 승격하기 전에 기본 인스턴스가 계속 사용 가능하며 클라이언트를 지원하는 경우 다음을 수행해야 합니다.

  1. 기본 인스턴스에 대한 모든 쓰기를 중지합니다.
  2. 복제본의 복제 상태를 확인합니다(MySQL 클라이언트 탭의 안내 참조).
  3. 복제본이 복제되는지 확인한 후 Seconds_Behind_Master 측정 항목으로 보고되는 복제 지연 시간이 0이 될 때까지 기다려야 합니다.

그렇지 않으면 기본 인스턴스에 커밋된 일부 트랜잭션이 새로 승격된 인스턴스에서 누락될 수 있습니다.

복제본을 독립형 인스턴스로 승격하려면 다음 안내를 따르세요.

콘솔

  1. Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

    Cloud SQL 인스턴스로 이동

  2. 복제본 인스턴스의 이름을 클릭하여 선택합니다.
  3. 복제본 승격을 클릭합니다.
  4. 확인을 클릭합니다.

gcloud

gcloud sql instances promote-replica REPLICA_NAME
  

REST v1

명령줄 프롬프트에서 이 cURL 명령어를 실행하려면 gcloud auth print-access-token 명령어를 사용하여 액세스 토큰을 획득해야 합니다. Instances:promoteReplica 페이지의 API 탐색기를 사용하여 REST API 요청을 보낼 수도 있습니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

  • project-id: 프로젝트 ID
  • replica-name: 복제본 인스턴스의 이름

HTTP 메서드 및 URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

다음과 비슷한 JSON 응답이 표시됩니다.

REST v1beta4

명령줄 프롬프트에서 이 cURL 명령어를 실행하려면 gcloud auth print-access-token 명령어를 사용하여 액세스 토큰을 획득해야 합니다. Instances:promoteReplica 페이지의 API 탐색기를 사용하여 REST API 요청을 보낼 수도 있습니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

  • project-id: 프로젝트 ID
  • replica-name: 복제본 인스턴스의 이름

HTTP 메서드 및 URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

다음과 비슷한 JSON 응답이 표시됩니다.

승격된 인스턴스가 올바르게 구성되었는지 확인합니다. 특별히 필요한 경우 고가용성 인스턴스를 구성하는 것이 좋습니다.

동시 복제 구성

복제 성능 관리를 위해서는 복제 지연을 줄이는 것이 중요합니다. 복제 지연은 읽기 복제본 업데이트가 기본 인스턴스 업데이트보다 뒤쳐지는 경우에 발생합니다. 이 섹션에서는 사용자가 병렬 복제를 사용 설정하여 복제 지연을 줄일 수 있는 방법을 설명합니다.

MySQL 복제에서 복제 SQL 스레드는 읽기 복제본의 릴레이 로그에 수집되는 트랜잭션을 실행하는 데 사용됩니다. 병렬 복제는 이러한 트랜잭션을 실행할 수 있는 SQL 스레드 수를 늘려 복제 지연을 줄입니다. 병렬 복제가 사용 설정된 읽기 복제본을 멀티스레드 복제본이라고 부릅니다.

병렬 복제는 MySQL용 Cloud SQL의 다음 세 가지 시나리오에서 사용할 수 있습니다.

편의를 위해 이 페이지에서는 '기본 인스턴스'와 '읽기 복제본'이라는 용어를 사용합니다.

병렬 복제 플래그를 변경하는 기본 단계

병렬 복제를 사용 설정하는 단계는 다음과 같습니다.

  1. 읽기 복제본에서 복제를 사용 중지합니다.
  2. 읽기 복제본에서 병렬 복제 플래그를 설정합니다. gcloud 명령어를 사용하여 플래그를 설정합니다. 복제가 사용 중지되면 Google Cloud Console 옵션도 사용 중지됩니다.
  3. 읽기 복제본에서 복제를 사용 설정합니다.
  4. 필요한 경우 기본 인스턴스에서 병렬 복제 성능을 최적화하기 위한 플래그를 설정합니다.

읽기 복제본: 병렬 복제 플래그

MySQL용 Cloud SQL은 읽기 복제본에서 병렬 복제를 위한 여러 플래그를 지원합니다. 플래그에 대한 자세한 내용은 다음 링크를 클릭하여 MySQL 8.0 문서를 참조하세요.

이러한 플래그를 변경해도 읽기 복제본이 다시 시작되지 않습니다.

다음 표에는 이러한 플래그의 허용 범위와 기본값이 포함되어 있습니다.

읽기 복제본 플래그 허용되는 값 MySQL 5.7 기본값 MySQL 8.0 이상 기본값
replica_parallel_workers 0-1024 0 0(MySQL 8.0.26 이하)
4(MySQL 8.0.27 이상)
replica_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE(MySQL 8.0.26 이하)
LOGICAL_CLOCK(MySQL 8.0.27 이상)
replica_preserve_commit_order ON, OFF OFF OFF(MySQL 8.0.26 이하)
ON(MySQL 8.0.27 이상)
replica_pending_jobs_size_max 1024-1GB 16MB 128MB

replica_preserve_commit_order 플래그는 복제본의 릴레이 로그에서 실행되는 트랜잭션 시퀀스의 격차를 방지합니다.

replica_preserve_commit_order=1 설정에는 다음이 필요합니다.

replica_pending_jobs_size_max 플래그는 아직 적용되지 않은 이벤트를 보유한 적용 큐에 사용할 수 있는 최대 메모리(바이트)를 설정합니다.

기본 인스턴스: 병렬 복제 플래그

MySQL용 Cloud SQL은 기본 인스턴스에서 사용할 여러 플래그를 지원합니다. 이러한 플래그를 사용하여 병렬 복제가 사용 설정된 연결된 읽기 복제본의 복제 성능을 조정할 수 있습니다. 플래그에 대한 자세한 내용은 다음 링크를 클릭하여 MySQL 8.0 문서를 참조하세요.

이러한 플래그를 변경해도 기본 인스턴스가 다시 시작되지 않습니다.

다음 표에는 이러한 플래그의 허용 범위와 기본값이 포함되어 있습니다.

기본 인스턴스 플래그 허용되는 값 MySQL 5.7 기본값 MySQL 8.0 기본값 MySQL 8.4 기본값
binlog_transaction_dependency_history_size 1-1000000 25000 25000 25000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER WRITESET 해당 사항 없음(MySQL 8.4에서 지원 중단됨)
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64 해당 사항 없음(MySQL 8.4에서 지원 중단됨)

MySQL 5.7에서 binlog_transaction_dependency_trackingWRITESET 또는 WRITESET_SESSION으로 설정된 경우 transaction_write_set_extractionOFF가 아닌 값(XXHASH64 또는 MURMUR32)으로 설정해야 합니다.

복제 상태 확인

Google Cloud 콘솔을 사용하여 복제본 인스턴스를 보거나 관리 클라이언트를 사용하여 인스턴스에 로그인하면 상태 및 측정항목 등 복제와 관련된 세부정보를 확인할 수 있습니다. gcloud CLI를 사용하면 복제 구성에 대한 요약을 볼 수 있습니다.

Cloud SQL 복제본 인스턴스의 복제 상태를 확인하기 전에
gcloud sql instances describe 명령어를 사용하여 인스턴스의 상태를 표시합니다. 따라서 복제본 인스턴스에 복제가 사용 설정되었는지 여부를 확인할 수 있습니다.

복제본 인스턴스에 사용할 수 있는 측정항목은 다음과 같습니다. (복제본 이외의 인스턴스를 포함하여 모든 인스턴스에 사용 가능한 추가 측정항목에 대해 자세히 알아보기)

측정항목설명
복제 상태
(cloudsql.googleapis.com/database/replication/state)

복제가 기본 인터페이스에서 복제본으로 로그를 스트리밍하는지 여부를 나타냅니다. 가능한 값은 다음과 같습니다.

  • Running
  • Stopped
  • Error

이 측정항목은 복제본의 I/O 및 SQL 스레드 모두에서 실행 중인 것으로 보고되면 Running을 보고합니다. 자세한 내용은슬레이브 I/O 스레드 실행 상태슬레이브 SQL 스레드 실행 상태 또는 MySQL 참조 설명서의 복제 상태 확인을 참조하세요.

복제 지연
(cloudsql.googleapis.com/database/replication/replica_lag)

복제본의 상태가 기본 인스턴스의 상태보다 지연되는 시간입니다. 이는 (1) 현재 시간과 (2) 기본 인스턴스가 복제본에서 현재 적용 중인 트랜잭션을 커밋한 타임스탬프 간의 차이에 해당합니다. 특히 복제본이 쓰기를 수신했더라도 아직 데이터베이스에 적용되지 않았다면 쓰기가 지연된 것으로 간주할 수 있습니다.

연쇄 복제본의 경우 각 기본 복제본 쌍은 별도로 모니터링되며 엔드 투 엔드(기본에서 복제본) 지연을 유발하는 단일 측정항목이 없습니다.

이 측정항목은 복제본에서 SHOW REPLICA STATUS가 실행될 때 Seconds_Behind_Master 값을 보고합니다. 자세한 내용은 MySQL 참조 설명서의 복제 상태 확인을 참조하세요.

네트워크 지연
(cloudsql.googleapis.com/database/replication/network_lag)

복제본의 IO 스레드에 도달하도록 기본 데이터베이스에 binlog를 작성하는 데 걸리는 시간(초)입니다.

network_lag가 0이거나 이를 무시할 수 있지만 `replica_lag`가 높으면 SQL 스레드가 복제 변경사항을 빠르게 적용할 수 없음을 나타냅니다.

슬레이브 I/O 스레드 실행 상태
(cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state)

복제본에서 기본 인스턴스의 바이너리 로그 읽기를 위한 I/O 스레드가 실행 중인지 여부를 나타냅니다. 가능한 값은 다음과 같습니다.

  • Yes
  • No
  • Connecting

이 측정항목은 복제본에서 SHOW REPLICA STATUS가 실행될 때 Slave_IO_Running 값을 보고합니다. 자세한 내용은 MySQL 참조 설명서의 복제 상태 확인을 참조하세요.

슬레이브 SQL 스레드 실행 상태
(cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state)

복제본에서 릴레이 로그의 이벤트 실행에 대한 SQL 스레드가 실행 중인지 여부를 나타냅니다. 가능한 값은 다음과 같습니다.

  • Yes
  • No
  • Connecting

이 측정항목은 복제본에서 SHOW REPLICA STATUS가 실행될 때 Slave_SQL_Running 값을 보고합니다. 자세한 내용은 MySQL 참조 설명서의 복제 상태 확인을 참조하세요.

복제 상태를 확인하려면 다음 안내를 따르세요.

콘솔

Cloud SQL은 기본 Cloud SQL 모니터링 대시보드Replication StateReplication Lag 측정항목을 보고합니다.

리전 내 및 리전 간 복제본의 외부 측정항목과 외부 서버의 복제본을 보려면 커스텀 대시보드를 만들고 모니터링할 측정항목을 추가합니다.

  1. Google Cloud 콘솔에서 Monitoring 페이지로 이동합니다.

    모니터링으로 이동

  2. 대시보드 탭을 선택합니다.
  3. 대시보드 만들기를 클릭합니다.
  4. 대시보드의 이름을 지정하고 확인을 클릭합니다.
  5. 차트 추가를 클릭합니다.
  6. 리소스 유형에서 Cloud SQL 데이터베이스를 선택합니다.
  7. 다음 중 하나를 수행합니다.
    1. 복제 상태 측정항목 모니터링: 측정항목 선택 필드에 Replication state를 입력합니다. 그런 다음 state = "Running"에 대한 필터를 추가합니다. 이 차트는 복제가 실행 중이면 1을, 그렇지 않으면 0을 표시합니다.
    2. 복제 지연 측정항목 모니터링: 측정항목 선택 필드에 replica_lag를 입력합니다. 이 차트에서는 복제본의 상태가 기본 인스턴스보다 지연되는 시간을 보여줍니다.
    3. 복제본의 I/O 스레드 상태 모니터링: 측정항목 선택 필드에 Slave I/O thread running state를 입력합니다. 그런 다음 state = "Yes" 필터를 추가합니다. 차트에는 스레드가 실행 중인 경우 1이, 그렇지 않은 경우 0이 표시됩니다.
    4. 복제본의 SQL 스레드 상태 모니터링: 측정항목 선택 필드에 Slave SQL thread running state를 입력합니다. 그런 다음 state = "Yes" 필터를 추가합니다. 차트에는 스레드가 실행 중인 경우 1이, 그렇지 않은 경우 0이 표시됩니다.

gcloud

복제 인스턴스의 경우 다음을 사용하여 복제 상태를 확인합니다.

gcloud sql instances describe REPLICA_NAME

출력에서 databaseReplicationEnabled 속성 및 masterInstanceName 속성을 확인합니다.

기본 인스턴스의 경우 다음을 사용하여 복제본이 있는지 확인합니다.

gcloud sql instances describe PRIMARY_INSTANCE_NAME

출력에서 replicaNames 속성을 확인합니다.

mysql 클라이언트

  1. MySQL 클라이언트로 복제본에 연결합니다.

    자세한 내용은 외부 애플리케이션 연결 옵션을 참조하세요.

  2. 복제본 상태를 확인합니다.
    SHOW REPLICA STATUS \G

    명령어 출력에서 다음 측정항목을 확인합니다.

    • Master_Host: 기본 인스턴스의 이름입니다.
    • Slave_IO_Running, Slave_SQL_Running: 각각 I/O 및 SQL 스레드의 실행 여부를 나타냅니다. 스레드는 기본 인스턴스에서 복제본의 릴레이 로그로 이벤트를 전송하고, 릴레이 로그에서 이벤트를 실행합니다. 스레드가 실행 중인 경우 측정항목 값은 Yes입니다. 복제를 활성화하려면 두 스레드 모두 실행 중이어야 합니다.
    • Seconds_Behind_Master: 복제본이 기본 인스턴스의 트랜잭션을 처리하는 데 지연되는 시간(초), 즉 (1) 현재 시간과 (2) 기본 인스턴스가 현재 복제본에 적용 중인 트랜잭션을 커밋한 원래 타임스탬프 간의 차이. 복제가 손상되면 값은 NULL입니다.
    • Master_Log_file, Read_Master_Log_Pos,Relay_Master_Log_File, Exec_Master_Log_Pos: 이러한 측정항목은 I/O 스레드에서 이벤트를 읽은(Master_Log_fileRead_Master_Log_Pos) 좌표(파일 이름과 오프셋), SQL 스레드에서 이벤트를 실행한(Relay_Master_Log_FileExec_Master_Log_Pos) 좌표(파일 이름과 오프셋)를 나타냅니다. 이러한 측정항목이 동일한 경우(즉 Master_Log_fileRelay_Master_Log_File과 동일하고 Read_Master_Log_PosExec_Master_Log_Pos와 동일한 경우), 복제본은 기본 인스턴스에서 수신한 모든 이벤트를 처리합니다.

이 명령어의 출력에 대한 자세한 내용은 복제 상태 확인에 대한 MySQL 문서를 참조하세요.

문제 해결

문제 문제 해결
생성 시 읽기 복제본이 복제를 시작하지 않음 로그 파일에 더 구체적인 오류가 있을 수 있습니다. Cloud Logging의 로그를 검사하여 실제 오류를 찾으세요.
읽기 복제본을 만들 수 없음 - invalidFlagValue 오류 요청의 플래그 중 하나가 잘못되었습니다. 명시적으로 제공한 플래그 또는 기본값으로 설정된 플래그일 수 있습니다.

먼저 max_connections 플래그의 값이 기본 값보다 크거나 같은지 확인하세요.

max_connections 플래그가 적절하게 설정된 경우 Cloud Logging에서 로그를 검사하여 실제 오류를 확인하세요.

읽기 복제본을 만들 수 없음 - 알 수 없는 오류 로그 파일에 더 구체적인 오류가 있을 수 있습니다. Cloud Logging의 로그를 검사하여 실제 오류를 찾으세요.

오류가 set Service Networking service account as servicenetworking.serviceAgent role on consumer project이면 Service Networking API를 사용 중지했다가 다시 사용 설정합니다. 이렇게 하면 프로세스를 계속 진행하는 데 필요한 서비스 계정이 생성됩니다.

디스크가 가득 참 복제본을 만드는 동안 기본 인스턴스 디스크 크기가 가득 찰 수 있습니다. 기본 인스턴스를 수정하여 더 큰 디스크 크기로 업그레이드합니다.
복제본 인스턴스가 너무 많은 메모리를 사용하고 있습니다. 복제본은 임시 메모리를 사용하여 자주 요청되는 읽기 작업을 캐시하므로 기본 인스턴스보다 더 많은 메모리를 사용할 수 있습니다.

복제본 인스턴스를 다시 시작하여 임시 메모리 공간을 회수합니다.

복제가 중지되었습니다. 최대 스토리지 한도에 도달했고 스토리지 자동 증가가 사용 설정되지 않았습니다.

인스턴스를 수정하여 automatic storage increase를 사용 설정합니다.

긴 복제 지연 시간이 지속적으로 발생함 쓰기 부하가 너무 높아 복제본이 처리할 수 없습니다. 복제본의 SQL 스레드가 IO 스레드를 따라잡을 수 없는 경우 복제 지연이 발생합니다. 일부 쿼리 또는 워크로드로 인해 특정 스키마에서 일시적이거나 영구적인 복제 지연이 발생할 수 있습니다. 복제 지연이 발생하는 일반적인 원인은 다음과 같습니다.
  • 복제본에 대한 쿼리의 속도가 느립니다. 문제를 찾아 수정하세요.
  • 모든 테이블에 고유/기본 키가 있어야 합니다. 테이블에 고유/기본 키가 없으면 업데이트할 때마다 복제본에서 전체 테이블 검사를 수행해야 합니다.
  • DELETE ... WHERE field < 50000000과 같은 쿼리의 경우 복제본에 다수의 업데이트가 쌓이게 되므로 행 기준 복제에서 복제 지연이 발생합니다.

가능한 솔루션은 다음과 같습니다.

  • 병렬 복제 구성
  • 읽기 복제본의 innodb_flush_log_at_trx_commit 플래그를 2로 설정합니다.

    이 플래그에 대한 자세한 내용은 플래그 사용 팁을 참조하세요.

  • 인스턴스를 수정하여 복제본 크기를 늘립니다.
  • 데이터베이스의 부하를 줄입니다.
  • 읽기 트래픽을 읽기 복제본으로 보냅니다.
  • 테이블 색인을 생성합니다.
  • 느린 쓰기 쿼리를 식별하고 수정합니다.
  • 복제본을 다시 만듭니다.
복제 지연 시간이 갑자기 증가합니다. 장기 실행 트랜잭션으로 인해 발생합니다. 트랜잭션(단일 문 또는 다중 문)이 소스 인스턴스에서 커밋되면 트랜잭션의 시작 시간이 바이너리 로그에 기록됩니다. 복제본에 이 바이너리 로그 이벤트가 수신되면 타임스탬프를 현재 타임스탬프와 비교해서 복제 지연 시간을 계산합니다. 따라서 소스에 장기 실행 트랜잭션이 있을 경우 복제본에서 즉각적인 큰 복제 지연을 일으킬 수 있습니다. 트랜잭션에서 행이 변경되는 정도가 크면 복제본에서도 이를 수행하기 위해 긴 시간이 소비됩니다. 이 기간 동안 복제 지연이 증가합니다. 복제본에서 이 트랜잭션이 완료된 다음의 캐치업 기간은 소스의 쓰기 워크로드 및 복제본의 처리 속도에 따라 달라집니다.

트랜잭션이 길어지는 것을 방지하기 위해 몇 가지 가능한 해결 방법이 있습니다.

  • 트랜잭션을 여러 개의 작은 트랜잭션으로 분할
  • 하나의 큰 쓰기 쿼리를 작은 배치로 분할
  • 긴 SELECT 쿼리를 DML이 혼합된 트랜잭션에서 분리하기
병렬 복제 플래그를 변경하면 오류가 발생합니다. 이러한 플래그 중 하나 이상에 잘못된 값이 설정되었습니다.

오류 메시지를 표시하는 기본 인스턴스에서 다음과 같이 병렬 복제 플래그를 설정합니다.

  1. binlog_transaction_dependency_trackingtransaction_write_set_extraction 플래그를 수정합니다.
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. slave_pending_jobs_size_max 플래그를 추가합니다.

    slave_pending_jobs_size_max=33554432

  3. transaction_write_set_extraction 플래그를 수정합니다.

    transaction_write_set_extraction=XXHASH64

  4. binlog_transaction_dependency_tracking 플래그를 수정합니다.

    binlog_transaction_dependency_tracking=WRITESET

제한 시간으로 인해 복제본을 만들지 못했습니다. 기본 인스턴스에서 커밋되지 않은 장기 실행 트랜잭션으로 인해 읽기 복제본을 만들지 못할 수 있습니다.

실행 중인 모든 쿼리를 중지한 후 복제본을 다시 만듭니다.

다음 단계