읽기 복제본 구성

MySQL | PostgreSQL | SQL Server

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

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

복제 사용 중지

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

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

복제 사용 중지 방법

콘솔

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

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

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"
  }
}

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

cURL(Linux, macOS, Cloud Shell)

참고: 다음 명령어는 gcloud init 또는 gcloud auth login을 실행하거나 gcloud CLI에 자동으로 로그인하는 Cloud Shell을 사용하여 사용자 계정으로 gcloud CLI에 로그인했다고 가정합니다. gcloud auth list를 실행하면 현재 활성 계정을 확인할 수 있습니다.

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name"

PowerShell(Windows)

참고: 다음 명령어는 gcloud init 또는 gcloud auth login을 실행하여 사용자 계정으로 gcloud CLI에 로그인했다고 가정합니다. gcloud auth list를 실행하면 현재 활성 계정을 확인할 수 있습니다.

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

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

HTTP 메서드 및 URL:

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

JSON 요청 본문:

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

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

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

복제 사용 설정

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

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

콘솔

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

Cloud SQL 인스턴스로 이동
복제본 인스턴스의 이름을 클릭하여 선택합니다.
복제 사용 설정을 클릭합니다.
확인을 클릭합니다.

gcloud

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

REST v1

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

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

HTTP 메서드 및 URL:

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

JSON 요청 본문:

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

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

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

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

HTTP 메서드 및 URL:

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

JSON 요청 본문:

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

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

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

복제본 승격

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

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

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

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

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

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

콘솔

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

Cloud SQL 인스턴스로 이동
복제본 인스턴스의 이름을 클릭하여 선택합니다.
복제본 승격을 클릭합니다.
확인을 클릭합니다.

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

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

cURL(Linux, macOS, Cloud Shell)

다음 명령어를 실행합니다.

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica"

PowerShell(Windows)

다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica" | Select-Object -Expand Content

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

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

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

HTTP 메서드 및 URL:

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

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

cURL(Linux, macOS, Cloud Shell)

다음 명령어를 실행합니다.

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica"

PowerShell(Windows)

다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica" | Select-Object -Expand Content

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

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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

복제 상태 확인

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

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

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

측정항목	설명
복제 상태 (`cloudsql.googleapis.com/database/replication/state`)	복제가 기본 인터페이스에서 복제본으로 로그를 스트리밍하는지 여부를 나타냅니다. 가능한 값은 다음과 같습니다. `Running` `Stopped` `Error` 이 측정항목은 다음 경우에 `Running`을 보고합니다. `pg_catalog.pg_stat_wal_receiver`는 '스트리밍' `status`를 보고합니다. 그리고 `pg_catalog.pg_is_wal_replay_paused()`는 'f'(false)를 보고합니다. 자세한 내용은 PostgreSQL 참조 설명서의 통계 수집기 및 시스템 관리 함수를 참조하세요.
복제 지연 (`cloudsql.googleapis.com/database/replication/replica_lag`)	복제본의 상태가 기본 인스턴스의 상태보다 지연되는 시간입니다. 이는 (1) 현재 시간과 (2) 기본 인스턴스가 복제본에서 현재 적용 중인 트랜잭션을 커밋한 타임스탬프 간의 차이에 해당합니다. 특히 복제본이 쓰기를 수신했더라도 아직 데이터베이스에 적용되지 않았다면 쓰기가 지연된 것으로 간주할 수 있습니다. 연쇄 복제본의 경우 각 기본 복제본 쌍은 별도로 모니터링되며 엔드 투 엔드(기본에서 복제본) 지연을 유발하는 단일 측정항목이 없습니다. 자세한 내용은 복제 지연을 참조하세요.
지연 바이트 (`cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag`)	읽기 복제본이 기본 인스터스보다 지연되는 바이트 수를 보고합니다. 각 복제본에 대해 4개의 시계열이 생성되며 다음 작업이 아직 처리되지 않은 기본 인스턴스의 미리 쓰기 로그에 있는 바이트 수가 표시됩니다. `sent_location`: 복제본으로 전송 `write_location`: 복제본이 디스크에 작성 `flush_location`: 복제본이 디스크에 플러시 `replay_location`: 복제본이 다시 재생 이러한 측정항목은 다양한 용도로 사용됩니다. 예를 들어 `replay_location`은 복제 지연(복제본에 적용되지 않은 기본 인스턴스에 커밋된 트랜잭션 수)을 나타내고 `flush_location`은 복제본 인스턴스에 영구적으로 기록되지 않은 트랜잭션 수를 나타냅니다. 이러한 측정항목은 `pg_catalog.pg_current_wal_lsn()`을 `pg_stat_replication`, `sent_lsn`, `write_lsn`, `flush_lsn` 또는 `replay_lsn` 필드 중 하나와 비교하여 계산합니다. 자세한 내용은 PostgreSQL 참조 설명서의 통계 수집기를 참조하세요.
최대 지연 바이트 (`cloudsql.googleapis.com/database/postgresql/external_sync/max_replica_byte_lag`)	외부 기본 인스턴스의 복제본은 이 인스턴스에 복제되는 모든 데이터베이스의 최대 복제 지연 시간(바이트)을 보고합니다. 이는 각 데이터베이스에 대해 복제본에서 수신하는 것으로 확인되지 않은 기본 인스턴스의 미리 쓰기 로그에 바이트 수로 정의됩니다. 이 측정항목은 기본 인스턴스에 쿼리를 전송하여 `pg_catalog.pg_current_wal_lsn()`을 복제본 인스턴스에 복제 중인 각 데이터베이스의 `confirmed_flush_lsn` 값과 비교하여 계산합니다. 자세한 내용은 PostgreSQL 참조 설명서의 통계 수집기를 참조하세요.

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

Console

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

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

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

모니터링으로 이동
대시보드 탭을 선택합니다.
대시보드 만들기를 클릭합니다.
대시보드의 이름을 지정하고 확인을 클릭합니다.
차트 추가를 클릭합니다.
리소스 유형에서 Cloud SQL 데이터베이스를 선택합니다.
다음 중 하나를 수행합니다.

복제 상태 측정항목 모니터링: 측정항목 선택 필드에 Replication state를 입력합니다. 그런 다음 state = "Running"에 대한 필터를 추가합니다. 이 차트는 복제가 실행 중이면 1을, 그렇지 않으면 0을 표시합니다.
읽기 복제본의 복제 지연(바이트 단위)을 모니터링하려면 측정항목 선택 필드에 Lag Bytes를 입력합니다. 그런 다음 replica_lag_type = "replay_location"에 대한 필터를 추가합니다. 차트에는 기본 인스턴스에서 커밋되었지만 아직 복제본에서 재생되지 않은 트랜잭션과 관련된 바이트 수가 표시됩니다.
외부 기본 인스턴스의 복제 지연 시간(바이트)을 모니터링하려면 측정항목 선택 필드에 Max Lag Bytes를 입력합니다. 차트에는 기본 인스턴스에서 커밋되었지만 아직 복제본에서 수신 확인하지 않은 트랜잭션과 관련된 바이트 수가 표시됩니다.

gcloud

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

gcloud sql instances describe REPLICA_NAME

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

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

gcloud sql instances describe PRIMARY_INSTANCE_NAME

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

psql 클라이언트

일부 복제본 상태 측정항목은 기본 인스턴스에서 생성되고 일부는 복제본에서 생성됩니다. 다음 단계에서는 PostgreSQL 클라이언트를 사용하여 아래 설명에 따라 복제본 또는 기본 인스턴스에 연결합니다.

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

기본 인스턴스에서 복제본 상태를 확인하려면 다음 안내를 따르세요.
```
select * from pg_stat_replication;
```
명령어 출력에서 다음 측정항목을 확인합니다.
- client_addr: 복제본 인스턴스의 IP 주소입니다.
- state: 릴레이 로그의 이벤트 실행에서 SQL 스레드가 실행 중인지 여부를 나타냅니다. 복제가 시작되면 값은 streaming입니다.
- replay_lag: 복제본 SQL 스레드가 기본 인스턴스보다 지연된 바이트 수입니다. 값은 O 또는 작은 값(바이트)입니다.
복제본 인스턴스에서 복제본 상태를 확인하려면 다음 안내를 따르세요.
```
select * from pg_stat_wal_receiver;
```
명령어 출력에서 다음 측정항목을 확인합니다.
- sender_host: 기본 인스턴스의 IP 주소입니다.
- status: 릴레이 로그의 이벤트 실행에서 SQL 스레드가 실행 중인지 여부를 나타냅니다. 복제가 시작되면 값은 streaming입니다.
- last_msg_send_time 및 last_msg_receipt_time: 이 두 타임스탬프 간의 차이가 지연 시간입니다.
복제가 일시중지되었는지 확인하려면 다음 안내를 따르세요.
```
select pg_is_wal_replay_paused();
```
복제가 일시중지되면 값은 t이고 그렇지 않으면 f입니다.

기본 인스턴스에서 수신되었지만 아직 적용되지 않은 트랜잭션이 있는지 확인하려면 다음 단계를 따르세요.
```
# for PostgreSQL 9.6
select pg_catalog.pg_last_xlog_receive_location(), pg_catalog.pg_last_xlog_replay_location();
# for PostgreSQL 10 and above
select pg_catalog.pg_last_wal_receive_lsn(), pg_catalog.pg_last_wal_replay_lsn();
```
두 값이 동일한 경우 복제본은 기본 인스턴스에서 수신한 모든 트랜잭션을 처리한 것입니다.

이 명령어의 출력에 대한 자세한 내용은 통계 수집기의 PostgreSQL 문서를 참조하세요.

문제 해결

문제	문제 해결
생성 시 읽기 복제본이 복제를 시작하지 않음	로그 파일에 더 구체적인 오류가 있을 수 있습니다. 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`를 사용 중지했다가 다시 사용 설정합니다. 이렇게 하면 프로세스를 계속 진행하는 데 필요한 서비스 계정이 생성됩니다.
디스크가 가득 참	복제본을 만드는 동안 기본 인스턴스 디스크 크기가 가득 찰 수 있습니다. 기본 인스턴스를 수정하여 더 큰 디스크 크기로 업그레이드합니다.
디스크 공간이 현저하게 증가함	데이터를 추적하는 데 적극적으로 사용되지 않는 슬롯이 있으면 PostgreSQL이 WAL 세그먼트를 무기한 저장합니다. 그로 인해 디스크 공간도 무제한으로 증가합니다. Cloud SQL에서 논리적 복제 및 디코딩 기능을 사용하는 경우 복제 슬롯이 자동으로 생성 및 삭제됩니다. 사용되지 않는 복제 슬롯은 `pg_replication_slots` 시스템 뷰를 쿼리하고 `active` 열로 필터링을 수행하여 확인할 수 있습니다. `pg_drop_replication_slot` 명령어를 사용하여 WAL 세그먼트를 삭제하기 위해 사용하지 않는 슬롯을 삭제할 수 있습니다.
복제본 인스턴스가 너무 많은 메모리를 사용하고 있습니다.	복제본은 임시 메모리를 사용하여 자주 요청되는 읽기 작업을 캐시하므로 기본 인스턴스보다 더 많은 메모리를 사용할 수 있습니다. 복제본 인스턴스를 다시 시작하여 임시 메모리 공간을 회수합니다.
복제가 중지되었습니다.	최대 스토리지 한도에 도달했고 스토리지 자동 증가가 사용 설정되지 않았습니다. 인스턴스를 수정하여 `automatic storage increase`를 사용 설정합니다.
긴 복제 지연 시간이 지속적으로 발생함	쓰기 부하가 너무 높아 복제본이 처리할 수 없습니다. 복제본의 SQL 스레드가 IO 스레드를 따라잡을 수 없는 경우 복제 지연이 발생합니다. 일부 쿼리 또는 워크로드로 인해 특정 스키마에서 일시적이거나 영구적인 복제 지연이 발생할 수 있습니다. 복제 지연이 발생하는 일반적인 원인은 다음과 같습니다. 복제본에 대한 쿼리의 속도가 느립니다. 문제를 찾아 수정하세요. 모든 테이블에 고유/기본 키가 있어야 합니다. 테이블에 고유/기본 키가 없으면 업데이트할 때마다 복제본에서 전체 테이블 검사를 수행해야 합니다. `DELETE ... WHERE field < 50000000`과 같은 쿼리의 경우 복제본에 다수의 업데이트가 쌓이게 되므로 행 기준 복제에서 복제 지연이 발생합니다. 가능한 솔루션은 다음과 같습니다. 인스턴스를 수정하여 복제본 크기를 늘립니다. 데이터베이스의 부하를 줄입니다. 읽기 트래픽을 읽기 복제본으로 보냅니다. 테이블 색인을 생성합니다. 느린 쓰기 쿼리를 식별하고 수정합니다. 복제본을 다시 만듭니다.
PostgreSQL 9.6에서 색인을 다시 빌드할 때 오류가 발생함	PostgreSQL에서 특정 색인을 다시 빌드해야 한다는 오류 메시지가 표시됩니다. 이 작업은 기본 인스턴스에서만 수행할 수 있습니다. 새 복제본 인스턴스를 만들면 곧 같은 오류가 다시 발생합니다. PostgreSQL 10 미만의 PostgreSQL에서는 해시 색인이 복제본에 전파되지 않습니다. 해시 색인을 사용해야 하는 경우 PostgreSQL 10 이상으로 업그레이드하세요. 그러지 않고 복제본도 사용하려면 PostgreSQL 9.6에서 해시 색인을 사용하지 마세요.
기본 인스턴스에 대한 쿼리는 항상 실행됨	복제본을 만든 후에는 기본 인스턴스에서 `SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica'` 쿼리를 계속 실행해야 합니다.
제한 시간으로 인해 복제본을 만들지 못함	기본 인스턴스에서 커밋되지 않은 장기 실행 트랜잭션으로 인해 읽기 복제본을 만들지 못할 수 있습니다. 실행 중인 모든 쿼리를 중지한 후 복제본을 다시 만듭니다.
기본 인스턴스와 복제본의 vCPU 크기가 다른 경우 쿼리 최적화 도구에서 vCPU 크기를 고려하므로 쿼리 성능 문제가 발생할 수 있습니다.	이 문제를 해결하려면 다음 단계를 완료하시기 바랍니다. log_duration 플래그를 사용 설정하고 `log_statement` 매개변수를 `ddl`로 설정합니다. 이렇게 하면 데이터베이스의 쿼리와 실행 시간 모두 제공됩니다. 그러나 워크로드에 따라 성능 문제가 발생할 수 있습니다. 기본 인스턴스와 읽기 복제본 모두에서 쿼리에 `explain analyze`를 실행합니다. 쿼리 계획을 비교하고 차이점을 확인합니다. 특정 쿼리이면 쿼리를 수정합니다. 예를 들어 조인 순서를 변경하여 성능이 향상되는지 확인할 수 있습니다.

다음 단계

읽기 복제본 생성 방법 알아보기
복제 요구사항 및 권장사항 자세히 알아보기