Menggunakan pemulihan dari bencana (DR) lanjutan

Halaman ini menjelaskan cara menggunakan disaster recovery (DR) lanjutan. DR lanjutan menyediakan dua kemampuan utama:

  • Failover replika memungkinkan Anda melakukan failover instance utama ke replika DR segera jika terjadi kegagalan region.
  • Pengalihan memungkinkan Anda membalikkan peran instance utama dan replika DR tanpa kehilangan data. Anda dapat menggunakan pengalihan untuk memulihkan deployment ke status deployment aslinya setelah failover replika, atau Anda dapat menggunakan pengalihan untuk menguji DR.

DR lanjutan hanya didukung di instance edisi Cloud SQL Enterprise Plus.

Sebelum memulai

Jika Anda berencana menggunakan Google Cloud SDK, Anda harus menggunakan versi 502.0.0 atau yang lebih baru. Untuk memeriksa versi Google Cloud SDK, jalankan gcloud --version. Untuk mengupdate Google Cloud SDK, jalankan gcloud components update.

Untuk menginstal Google Cloud SDK, lihat Menginstal gcloud CLI.

Menetapkan replika DR

Untuk melakukan DR lanjutan, Anda harus menetapkan replika DR lintas region terlebih dahulu.

Persyaratan instance utama

Instance utama harus berupa instance edisi Cloud SQL Enterprise Plus dan memiliki replika DR yang ditetapkan.

Jika Anda membuat instance Cloud SQL dengan endpoint tulis DNS, instance utama Anda harus memiliki konfigurasi SSL yang sama dengan replika DR yang ditetapkan sebelum Anda memanggil operasi pengalihan atau failover replika. Misalnya, jika Anda mengonfigurasi replika DR untuk menerapkan enkripsi SSL, tetapi instance utama mengizinkan koneksi yang tidak dienkripsi, klien tidak akan dapat terhubung ke instance utama baru setelah operasi pengalihan atau failover selesai.

Persyaratan replika DR

Replika baca DR yang ditetapkan harus memenuhi persyaratan berikut:

  • Harus berupa instance edisi Cloud SQL Enterprise Plus

  • Harus memiliki versi utama dan minor database yang sama dengan instance utama, yang menjalankan MySQL 8.0.31 atau yang lebih baru

  • Harus mengaktifkan logging biner. Anda tidak dapat menonaktifkan logging biner saat instance ditetapkan sebagai replika DR.

    Untuk mengaktifkan logging biner untuk replika, jalankan perintah berikut:

     gcloud sql instances patch --enable-bin-log REPLICA_NAME

  • Harus berada di region yang berbeda dengan instance utama

  • Harus berupa replika baca langsung; tidak boleh berupa replika bertingkat

  • Selain menggunakan nilai default, replika DR tidak boleh memiliki salah satu flag berikut yang dikonfigurasi:

    • replicate_do_db
    • replicate_ignore_db
    • replicate_do_table
    • replicate_wild_do_table
    • replicate_ignore_table
    • replicate_wild_ignore_table

  • Harus menyimpan log transaksi yang digunakan untuk PITR di Cloud Storage

  • Tidak dapat menjadi replika eksternal

Rekomendasi replika DR

Bagian ini memberikan rekomendasi untuk replika DR Anda. Rekomendasi berikut dapat membantu Anda menghindari masalah performa dalam deployment:

  • Gunakan ukuran disk yang sama dengan instance utama atau aktifkan pertumbuhan otomatis.
  • Gunakan konfigurasi HA yang konsisten. Jika Anda mengaktifkan HA di instance utama, aktifkan juga HA di replika DR.
  • Gunakan konfigurasi cache data yang konsisten. Jika Anda mengaktifkan cache data di instance utama, aktifkan juga cache data di replika DR.
  • Konfigurasikan flag database yang sesuai untuk replika DR Anda sebelum dan setelah operasi pengalihan atau failover replika.
  • Gunakan jenis (tingkat) dan ukuran mesin yang sama untuk instance utama dan replika DR.

Membuat replika untuk memenuhi persyaratan replika DR

Jika instance utama belum memiliki replika baca lintas region yang memenuhi persyaratan replika DR, buat replika baca lintas region.

Konsol

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Temukan instance utama.
  3. Di kolom Tindakan, klik menu Tindakan Lainnya.
  4. Pilih Buat replika baca.
  5. Di kolom Instance ID, masukkan nama untuk DR replica.
  6. Di kolom Database version, versi utama yang sama dari instance utama dipilih untuk Anda.
  7. Jika Anda menggunakan MySQL 8.0, di kolom Minor version, pertahankan versi minor yang telah dipilih sebelumnya. Replika DR dan instance utama harus memiliki versi minor database yang sama.
  8. Di bagian Choose a region and zonal availability pada halaman, lakukan hal berikut:
    • Pilih region yang _berbeda_ dari region instance utama Anda.
    • Opsional. Pilih Multiple zones untuk replika DR.
    • Opsional. Pilih Primary dan Secondary zones untuk replika DR.
  9. Di bagian Customize your instance pada halaman, Anda dapat memperbarui setelan untuk replika DR. Untuk mengetahui detail selengkapnya tentang setiap setelan, lihat halaman Tentang setelan instance.
  10. Untuk Machine shapes, pilih jenis mesin yang sama dengan instance utama Anda.
  11. Untuk Flags, konfigurasikan flag apa pun yang diperlukan untuk database Anda.
  12. Klik Buat replika.

Cloud SQL membuat cadangan instance utama dan membuat replika. Anda akan dikembalikan ke halaman instance untuk instance utama.

gcloud

Untuk membuat replika yang memenuhi persyaratan replika DR, jalankan perintah berikut:

gcloud sql instances create REPLICA_NAME \
   --master-instance-name=PRIMARY_INSTANCE_NAME \
   --region=REPLICA_REGION_NAME \
   --database-version=DATABASE_VERSION \
   --tier=MACHINE_TYPE \
   --availability-type=AVAILABILITY_TYPE
   --edition="ENTERPRISE_PLUS"

Ganti variabel berikut:

  • REPLICA_NAME: nama replika DR.
  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • REPLICA_REGION_NAME: tentukan region yang berbeda dengan region instance utama.
  • DATABASE_VERSION: tentukan string versi yang cocok dengan versi utama dan versi minor database instance utama, misalnya MYSQL_8_0_31 .

    Versi utama dan minor database harus sama untuk replika utama dan DR.

  • MACHINE_TYPE: tentukan jenis mesin yang sama dengan instance utama. Sebaiknya jenis mesin cocok dengan jenis mesin instance utama.
  • AVAILABILITY_TYPE: jika instance utama dikonfigurasi untuk ketersediaan tinggi, sebaiknya tentukan REGIONAL untuk mengaktifkan ketersediaan tinggi.
  • EDITION: tentukan ENTERPRISE_PLUS.

Terraform

Untuk membuat replika DR, gunakan resource Terraform.

resource "google_sql_database_instance" "original-primary" {
  name   = "mysql-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "MYSQL_8_0"
  instance_type    = "CLOUD_SQL_INSTANCE"

  settings {
    # Specify a tier that supports Cloud SQL Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # You must enable automated backups and binary logging.
      enabled            = true
      binary_log_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

resource "google_sql_database_instance" "dr-replica" {
  name = "mysql-dr-replica-instance"
  # DR replica must be in a different region than the region of the primary instance.
  region = "us-west2"
  # DR replica must be the same database version as the primary instance.
  database_version = "MYSQL_8_0"
  instance_type    = "READ_REPLICA_INSTANCE"
  # Specify the primary instance as the master instance.
  master_instance_name = google_sql_database_instance.original-primary.name

  settings {
    # DR replica must be in the same tier as your primary instance and support Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

REST v1

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • PROJECT_ID: ID atau nomor project dari project Google Cloud instance utama dan replika DR.
  • String versi DATABASE_VERSION: yang cocok dengan versi utama dan versi minor database instance utama, misalnya MYSQL_8_0_31. Versi database harus sama untuk replika utama dan DR.
  • REPLICA_NAME: nama instance replika DR yang Anda buat.
  • REPLICA_REGION: region instance replika DR. Region replika harus berbeda dengan region instance utama.
  • MACHINE_TYPE: tentukan jenis mesin yang sama dengan instance utama. Sebaiknya pilih jenis mesin yang sama dengan instance utama.
  • AVAILABILITY_TYPE: jika instance utama dikonfigurasi untuk ketersediaan tinggi, sebaiknya tentukan REGIONAL untuk mengaktifkan ketersediaan tinggi.

Metode HTTP dan URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

Meminta isi JSON: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

REST v1beta4

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • PROJECT_ID: ID atau nomor project dari project Google Cloud instance utama dan replika DR.
  • String versi DATABASE_VERSION: yang cocok dengan versi utama dan versi minor database instance utama, misalnya MYSQL_8_0_31. Versi database harus sama untuk replika utama dan DR.
  • REPLICA_NAME: nama instance replika DR yang Anda buat.
  • REPLICA_REGION: region instance replika DR. Region replika harus berbeda dengan region instance utama.
  • MACHINE_TYPE: tentukan jenis mesin yang sama dengan instance utama. Sebaiknya ukuran disk sesuai dengan ukuran disk instance utama.
  • AVAILABILITY_TYPE: jika instance utama dikonfigurasi untuk ketersediaan tinggi, sebaiknya tentukan REGIONAL untuk mengaktifkan ketersediaan tinggi.

Metode HTTP dan URL: 

POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances

Meminta isi JSON: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

Menetapkan replika DR untuk instance utama

Prosedur berikut menjelaskan cara menetapkan salah satu replika lintas region dari instance utama sebagai replika DR untuk pengalihan atau failover replika.

Konsol

Untuk menetapkan replika DR bagi instance utama, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Cari dan pilih instance utama. Halaman Ringkasan untuk instance utama akan muncul.
  3. Di menu navigasi, klik Replicas.
  4. Dalam daftar replika baca, temukan replika baca lintas region yang ingin Anda tetapkan sebagai replika DR.
  5. Untuk replika, klik tombol more_vert Actions, lalu pilih Designate as DR replica.
  6. Klik Konfirmasi.

gcloud

Untuk menetapkan replika DR bagi instance utama, gunakan perintah berikut:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
   --failover-dr-replica-name=REPLICA_NAME

Ganti variabel berikut:

  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • REPLICA_NAME: nama replika DR.

Terraform

Untuk menetapkan replika DR untuk instance utama, gunakan resource Terraform.

data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name   = "mysql-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "MYSQL_8_0"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    # Designate the DR replica.
    # The format for setting the DR replica is `project-id:dr-replica-name`.
    failover_dr_replica_name = "${data.google_project.default.project_id}:mysql-dr-replica-instance"
  }

  settings {
    # Specify a tier that supports Cloud SQL Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # You must enable automated backups and binary logging.
      enabled            = true
      binary_log_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name = "mysql-dr-replica-instance"
  # DR replica must be in a different region than the region of the primary instance.
  region = "us-west2"
  # DR replica must be the same database version as the primary instance.
  database_version = "MYSQL_8_0"
  instance_type    = "READ_REPLICA_INSTANCE"
  # Specify the primary instance as the master instance.
  master_instance_name = google_sql_database_instance.original-primary.name

  settings {
    # DR replica must be in the same tier as your primary instance and support Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

REST v1

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • REPLICA_NAME: nama replika DR.

Metode HTTP dan URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Meminta isi JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

REST v1beta4

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • REPLICA_NAME: nama replika DR.

Metode HTTP dan URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Meminta isi JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

Mengubah penetapan replika DR

Jika replika memenuhi persyaratan, Anda dapat menetapkan replika lain sebagai replika DR. Replika DR lama kehilangan penetapan replika DR.

Konsol

Untuk mengubah replika DR untuk instance utama, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Cari dan pilih instance utama. Halaman Ringkasan untuk instance utama akan muncul.
  3. Di menu navigasi, klik Replicas.
  4. Dalam daftar replika baca, temukan replika baca lintas region yang ingin Anda tetapkan sebagai replika DR baru.
  5. Untuk replika, klik tombol more_vert Actions, lalu pilih Designate as DR replica.

gcloud

Untuk mengubah replika DR, jalankan perintah designate lagi, dan tentukan replika DR yang berbeda.

REST

Untuk mengubah replika DR, buat permintaan API penetapan lagi, dan tentukan replika DR yang berbeda.

Melihat penetapan replika DR

Anda dapat memeriksa replika DR mana yang ditetapkan ke instance utama menggunakan gcloud CLI atau Cloud SQL Admin API. Anda juga dapat memeriksa apakah replika adalah replika DR yang ditetapkan.

Untuk mengetahui replika DR mana yang ditetapkan untuk instance utama, gunakan prosedur berikut.

Konsol

Untuk mengetahui replika baca mana yang merupakan replika DR yang ditetapkan untuk instance utama, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Cari dan pilih instance utama. Halaman Ringkasan untuk instance utama akan muncul.
  3. Di menu navigasi, klik Replicas.
  4. Dalam daftar replika baca, pastikan MySQL disaster recovery replica muncul di kolom Type untuk replika DR yang ditetapkan.

gcloud

Untuk mengetahui instance mana yang merupakan replika DR yang ditetapkan dari instance utama, gunakan perintah berikut:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Ganti variabel berikut:

  • PRIMARY_INSTANCE_NAME: nama instance utama

Output perintah ini berisi kolom bernama failoverDrReplica yang mengidentifikasi replika DR yang ditetapkan.

REST v1

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud yang berisi instance.
  • PRIMARY_INSTANCE_NAME: nama instance utama.

Metode HTTP dan URL: 

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

REST v1beta4

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud yang berisi instance.
  • PRIMARY_INSTANCE_NAME: nama instance utama.

Metode HTTP dan URL: 

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

Untuk memeriksa apakah replika adalah replika DR, gunakan salah satu prosedur berikut.

Konsol

Untuk memeriksa apakah instance replika adalah replika DR, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Temukan instance replika.
  3. Pastikan MySQL disaster recovery replica muncul di kolom Type untuk replika DR yang ditetapkan.

gcloud

Untuk memeriksa apakah instance replika adalah replika DR, jalankan perintah berikut:

gcloud sql instances describe REPLICA_NAME

Ganti variabel berikut:

  • REPLICA_NAME: nama replika baca yang ingin Anda periksa

Jika replika adalah replika DR, output perintah akan berisi kolom drReplica=true.

REST v1

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud yang berisi instance.
  • REPLICA_NAME: nama replika.

Metode HTTP dan URL: 

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima kode status berhasil (2xx) dan respons kosong.

REST v1beta4

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud yang berisi instance.
  • REPLICA_NAME: nama replika.

Metode HTTP dan URL: 

GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima kode status berhasil (2xx) dan respons kosong.

Menghapus replika DR

Anda dapat menghapus penetapan replika DR dari instance utama. Namun, jika tidak ada replika DR yang ditetapkan ke instance utama, Anda tidak dapat melakukan pengalihan atau failover replika.

Konsol

Untuk menghapus replika DR yang ditetapkan dari instance utama, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Cari dan pilih instance utama. Halaman Ringkasan untuk instance utama akan muncul.
  3. Di menu navigasi, klik Replicas.
  4. Dalam daftar replika baca, temukan replika baca lintas region yang ingin Anda hapus.
  5. Untuk replika, klik tombol more_vert Actions, lalu pilih Remove as DR replica.
  6. Klik Konfirmasi.

gcloud

Untuk menghapus penetapan replika DR, jalankan perintah berikut pada instance utama:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
  --clear-failover-dr-replica-name

Ganti variabel berikut:

  • PRIMARY_INSTANCE_NAME: nama instance utama yang ingin Anda hapus replika DR yang ditetapkan

REST v1

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud instance utama dan replika DR.
  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • Tetapkan kolom failoverDrReplicaName ke string kosong.

Metode HTTP dan URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Meminta isi JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

REST v1beta4

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud instance utama dan replika DR.
  • PRIMARY_INSTANCE_NAME: nama instance utama.
  • Tetapkan kolom failoverDrReplicaName ke string kosong.

Metode HTTP dan URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Meminta isi JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

Melakukan peralihan

Setelah menetapkan replika DR, Anda dapat melakukan operasi pengalihan. Namun, sebagai praktik terbaik, hindari melakukan operasi pengalihan dalam kondisi berikut:

  • Instance utama sedang digunakan secara aktif.
  • Operasi admin sedang berlangsung, seperti pencadangan otomatis atau pengaktifan atau penonaktifan ketersediaan tinggi (HA).

Untuk menghindari waktu tunggu habis, pertimbangkan untuk melakukan pengalihan saat volume transaksi rendah.

Saat pengalihan selesai, operasi akan mencadangkan instance utama baru (mantan replika DR) segera setelah instance utama baru dipromosikan. Setelah pencadangan ini selesai, pemulihan point-in-time (PITR) akan diaktifkan sepenuhnya pada instance utama baru. Pencadangan ini dapat memerlukan waktu antara 5 dan 15 menit, tergantung ukuran disk. Cakupan PITR hanya dimulai setelah pencadangan ini selesai.

Untuk mengurangi total waktu peralihan, Cloud SQL mengonfigurasi dan mengaktifkan PITR dalam operasi asinkron terpisah setelah peralihan selesai. Untuk mengetahui informasi selengkapnya tentang pertimbangan penggunaan PITR dengan DR lanjutan, lihat Menggunakan PITR dengan DR lanjutan.

Setelah operasi pengalihan selesai, Anda akan melihat bahwa arah replikasi dibalik.

Setelah instance utama lama Anda dikonfigurasi ulang sebagai replika baca, endpoint tulis DNS, yang sebelumnya di-resolve ke instance utama lama, akan di-resolve ke instance utama baru.

Jika Anda mengonfigurasi konektivitas keluar Private Service Connect pada replika disaster recovery (DR), setelah operasi pengalihan, saat replika DR dipromosikan ke instance utama, konektivitas keluar akan terus berfungsi pada instance utama baru yang dibuat. Jika Anda tidak mengonfigurasi konektivitas keluar pada replika disaster recovery (DR), agar layanan dapat terus berfungsi setelah operasi pengalihan, Anda harus mengaktifkan konektivitas keluar Private Service Connect pada instance utama baru.

Sebelum memulai

Sebelum Anda melakukan operasi pengalihan, lakukan hal berikut:

  • Menetapkan replika DR. Anda hanya dapat melakukan pengalihan antara instance utama dan replika DR yang ditetapkan.
  • Pastikan instance utama dan replika DR sedang online.
  • Jika Anda menggunakan endpoint tulis DNS, pastikan konfigurasi SSL untuk instance utama dan replika DR sama. Misalnya, jika replika DR dikonfigurasi untuk menerapkan enkripsi SSL, tetapi instance utama mengizinkan koneksi yang tidak dienkripsi, klien tidak akan dapat terhubung ke instance utama baru setelah operasi pengalihan selesai.
  • Ambil cadangan on-demand dari instance utama. Cadangan ini merupakan tindakan pencegahan jika Anda perlu melakukan pemulihan dari kegagalan yang tidak terduga.

Melakukan operasi pengalihan

Konsol

Untuk melakukan operasi pengalihan, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Temukan replika DR yang ditetapkan dari instance utama.
  3. Klik instance replika DR. Halaman Overview untuk replika DR akan muncul.
  4. Klik tombol Switchover.
  5. Di halaman Lakukan peralihan antara replika utama dan DR, masukkan nama instance utama di kolom ID Instance.
  6. Klik Switchover.

gcloud

Untuk melakukan operasi pengalihan, jalankan perintah berikut:

gcloud sql instances switchover REPLICA_NAME
   [--db-timeout=TIMEOUT_DURATION ]

Ganti variabel berikut:

  • REPLICA_NAME: nama replika DR yang ditetapkan yang Anda inginkan untuk bertukar peran dengan instance utama.
  • TIMEOUT_DURATION: opsional. periode waktu tunggu untuk memungkinkan penyelesaian operasi database pada instance.

    • Jika Anda tidak menentukan parameter ini, operasi pengalihan akan menyertakan waktu tunggu 10 menit.

    Anda dapat meningkatkan nilai waktu tunggu ini dengan menentukan parameter --db-timeout. Ganti TIMEOUT_DURATION dengan durasi jangka waktu hingga 24 jam, termasuk notasi awal untuk format. Misalnya, untuk 30 detik, tentukan 30s. Untuk 24 jam, tentukan 24h. Anda juga dapat menentukan unit pecahan jangka waktu dengan menggunakan desimal hingga 9 tempat. Misalnya, untuk 30,5 menit, tentukan 30.5m.

    Jika tidak memiliki operasi yang tertunda, Anda dapat mengurangi nilai waktu tunggu ini.

Terraform

Untuk memulai operasi pengalihan, gunakan resource Terraform. Untuk menjadikan replika DR sebagai instance utama baru, gunakan contoh pertama. Contoh ini berisi komentar untuk perubahan konfigurasi Terraform yang perlu Anda lakukan untuk mengalihkan instance utama dan replika DR.

#
# This sample provides the first part of the switchover operation and turns the DR replica
# into the new primary instance.
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "mysql-original-primary-instance"
  region           = "us-east1"
  database_version = "MYSQL_8_0"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:mysql-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled            = true
      binary_log_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "mysql-dr-replica-instance"
  region           = "us-west2"
  database_version = "MYSQL_8_0"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  # Remove or comment out the master_instance_name from the DR replica.
  # master_instance_name = google_sql_database_instance.original-primary.name
  # Add the original primary instance to a list of replicas for the new primary.
  replica_names = [google_sql_database_instance.original-primary.name]

  # Designate the original primary instance as the DR replica of the new primary instance.
  # The format for setting the DR replica is `project-id:dr-replica-name`.
  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Add a backup configuration section to enable automated backups and binary logging for the new primary instance.
      enabled            = true
      binary_log_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

Setelah membuat perubahan, update replika utama dan DR dengan menjalankan terraform plan. Pastikan output menyertakan Plan: 0 to add, 1 to change, 0 to destroy. Untuk melakukan pengalihan, jalankan terraform apply.

Pada tahap ini, instance utama asli adalah replika dari instance utama baru. Namun, perubahan tersebut tidak otomatis terlihat di status Terraform Anda. Untuk menjadikan instance utama asli sebagai replika instance utama baru di status Terraform Anda, gunakan contoh kedua. Contoh kedua memberikan komentar yang menjelaskan perubahan yang perlu Anda lakukan setelah menjalankan contoh pertama.

#
# This sample provides the second part of the switchover operation and makes the original primary instance
# a replica of the new primary instance. After you run `terraform apply` for this sample, you'll see
# the following message:
#
# "No changes. Your infrastructure matches the configuration.
#
# Terraform has compared your real infrastructure against your configuration and found no differences,
# so no changes are needed.
#
# Apply complete! Resources: 0 added, 0 changed, 0 destroyed."
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "mysql-original-primary-instance"
  region           = "us-east1"
  database_version = "MYSQL_8_0"
  # Change instance type for the original primary from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  # Set master_instance_name to the the new primary instance, the old DR replica.
  master_instance_name = "mysql-dr-replica-instance"
  # replica_names = [] # If you previously defined a replica_names field in your template, then delete the DR replica
  # (new primary) from the list of replicas.  Don't delete the entire replica_names field.
  # Instead set the field to an empty string. For example, replica_names = [""].

  replication_cluster {
    # This instance no longer requires a designated DR replica since it's a replica.
    # Remove the DR replica designation by setting the field to an empty string.
    failover_dr_replica_name = ""
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Disable automated backups because this instance is now a replica.
      enabled            = false
      binary_log_enabled = true
    }
  }
  deletion_protection = false
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "mysql-dr-replica-instance"
  region           = "us-west2"
  database_version = "MYSQL_8_0"
  instance_type    = "CLOUD_SQL_INSTANCE"
  replica_names    = [google_sql_database_instance.original-primary.name]


  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled            = true
      binary_log_enabled = true
    }
  }
  deletion_protection = false
}

Jika status Terraform Anda berhasil diperbarui, maka saat Anda menjalankan terraform plan terhadap sampel kedua, pesan yang mirip dengan berikut ini akan muncul:

No changes. Your infrastructure matches the configuration.

Jika Anda menjalankan terraform apply, Anda akan menerima pesan yang mirip dengan berikut ini:

Resources: 0 added, 0 changed, 0 destroyed.

REST v1

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project Google Cloud project instance utama dan replika DR.
  • REPLICA_NAME: nama replika DR.

Metode HTTP dan URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

REST v1beta4

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud instance utama dan replika DR.
  • REPLICA_NAME: nama replika DR.

Metode HTTP dan URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

Melakukan DR dengan memanggil failover replika

Jika terjadi kegagalan region atau bencana, Anda dapat melakukan DR dengan memanggil operasi failover replika ke replika DR yang Anda tentukan. Untuk melakukan failover replika, Anda mempromosikan replika DR yang ditetapkan. Berbeda dengan pengalihan, promosi replika DR dilakukan dengan segera.

Karena replika DR langsung mengambil peran instance utama, replika tersebut mungkin tidak memiliki semua data dari instance utama lama karena jeda replikasi. Oleh karena itu, failover replika dapat menyebabkan kehilangan data.

Sebagai bagian dari proses promosi, failover replika akan mencadangkan instance utama baru (mantan replika DR) tepat setelah replika DR menjadi instance utama baru. Setelah pencadangan ini selesai, pemulihan point-in-time (PITR) akan diaktifkan sepenuhnya di instance utama baru. Pencadangan ini dapat memerlukan waktu antara 5 dan 15 menit untuk diselesaikan, bergantung pada ukuran disk instance utama baru (dan lama). Selama periode pencadangan ini, PITR tidak tersedia.

Untuk mengurangi total waktu operasi failover replika, Cloud SQL mengonfigurasi dan mengaktifkan PITR dalam operasi asinkron terpisah setelah operasi failover selesai.

Saat instance utama lama kembali online, proses failover replika akan melakukan pencadangan. Setelah pencadangan ini dilakukan, instance utama lama akan dibuat ulang sebagai replika baca dari instance utama baru.

Untuk mengetahui informasi selengkapnya tentang pertimbangan penggunaan PITR dengan DR lanjutan, lihat Menggunakan PITR dengan DR lanjutan.

Setelah Anda memanggil operasi failover replika, endpoint tulis DNS, yang sebelumnya di-resolve ke instance utama lama, akan di-resolve ke instance utama baru.

Jika Anda mengonfigurasi konektivitas keluar Private Service Connect pada replika disaster recovery (DR), setelah operasi failover replika, saat replika DR dipromosikan ke instance utama, konektivitas keluar akan terus berfungsi pada instance utama baru yang dibuat. Jika Anda tidak mengonfigurasi konektivitas keluar pada replika disaster recovery (DR), maka agar layanan dapat terus berfungsi setelah operasi failover replika, Anda harus mengaktifkan konektivitas keluar Private Service Connect pada instance utama baru.

Sebelum memulai

Sebelum Anda dapat melakukan failover replika, lakukan hal berikut:

  • Jika Anda belum melakukannya, tentukan replika DR. Anda hanya dapat melakukan failover replika antara instance utama dan replika DR yang ditetapkan.
  • Pastikan replika DR online dan responsif.

Melakukan operasi failover replika

Konsol

Untuk melakukan operasi failover replika, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Temukan replika DR yang ditetapkan dari instance utama.
  3. Klik instance replika DR. Halaman Overview untuk replika DR akan muncul.
  4. Klik tombol Replica Failover.
  5. Di halaman Perform replica failover between the primary and DR replica, masukkan nama instance utama di kolom Instance ID untuk mengonfirmasi bahwa Anda ingin melanjutkan operasi.
  6. Untuk memulai failover replika, klik Replica Failover.

gcloud

Untuk memanggil failover replika ke replika DR, gunakan perintah berikut:

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

Ganti variabel berikut:

  • REPLICA_NAME: nama replika DR

REST v1

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud instance utama dan replika DR.
  • REPLICA_NAME: nama replika DR.
  • ENABLE_REPLICA_FAILOVER: tetapkan ke true untuk menggunakan failover replika. Jika Anda menetapkan ke false, API akan menggunakan metode promoteReplica reguler tanpa failover replika.

Metode HTTP dan URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

REST v1beta4

Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

  • PROJECT_ID: ID atau nomor project dari project Google Cloud instance utama dan replika DR.
  • REPLICA_NAME: nama replika DR.
  • ENABLE_REPLICA_FAILOVER: tetapkan ke true untuk menggunakan failover replika. Jika Anda menetapkan ke false, API akan menggunakan metode promoteReplica reguler tanpa failover replika.

Metode HTTP dan URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:

Anda akan menerima respons JSON yang mirip dengan yang berikut ini:

Memeriksa status failover replika

Failover replika terjadi dalam dua fase. Fase pertama adalah promosi replika DR. Fase kedua adalah pembuatan ulang instance utama lama sebagai replika baca.

Untuk memeriksa status failover replika, periksa status setiap fase.

  1. Periksa status fase pertama.

    Konsol

    Untuk memeriksa apakah replika DR telah dipromosikan ke instance mandiri, lakukan hal berikut:

    1. Di konsol Google Cloud , buka halaman Instance Cloud SQL.

      Buka Instance Cloud SQL

    2. Temukan nama replika DR yang Anda promosikan.
    3. Pastikan MySQL VERSION muncul di kolom Type untuk instance utama baru.

    gcloud

    Anda dapat memeriksa status dengan menjalankan perintah berikut:

    gcloud sql instances describe DR_REPLICA_NAME

    Ganti variabel berikut:

    • DR_REPLICA_NAME: nama replika DR yang dipromosikan

    Dalam output, pastikan kolom berikut muncul dan replika telah menjadi instance utama Cloud SQL mandiri:

    instanceType: CLOUD_SQL_INSTANCE

  2. Untuk memverifikasi penyelesaian fase kedua, periksa log operasi pada instance untuk pesan RECONFIGURE_OLD_PRIMARY.

    Kemunculan pesan ini bergantung pada kapan instance utama lama kembali online, yang dapat memerlukan waktu beberapa menit atau hari jika terjadi bencana.

    Untuk mengetahui informasi selengkapnya tentang cara memeriksa log operasi pada instance, lihat Melihat log instance.

Menggunakan PITR dengan DR lanjutan

Dengan beralih dan failover replika, segera setelah replika DR dipromosikan ke instance utama, perubahan berikut akan terjadi untuk mendukung pencadangan dan PITR:

  • Konfigurasi cadangan, termasuk penjadwalan pencadangan otomatis, disalin dari instance utama lama ke instance utama baru.
  • Jika dinonaktifkan, flag konfigurasi binlog akan diaktifkan untuk mengaktifkan PITR.

  • Cadangan baru dibuat untuk mendukung PITR pada instance utama baru.

  • Kebijakan retensi log transaksi disalin dari instance utama lama ke instance utama baru.

Untuk kebijakan retensi konfigurasi cadangan dan log transaksi, sebaiknya verifikasi bahwa setelan yang diwarisi dari instance utama lama sudah benar untuk instance utama baru.

Awal cakupan PITR

Di akhir operasi pengalihan, Cloud SQL akan menjadwalkan pencadangan otomatis dan mengambil cadangan pertama dari instance utama baru. Jika Anda ingin cakupan PITR dimulai lebih cepat, sebaiknya verifikasi bahwa pencadangan pertama berhasil. Instance utama yang baru dipromosikan memiliki cakupan PITR hanya setelah pencadangan otomatis pertama berhasil diselesaikan.

Untuk mengetahui informasi selengkapnya tentang cara melihat cadangan yang tersedia untuk instance, lihat Melihat daftar cadangan.

Cakupan PITR untuk instance selama peralihan dan failover replika

Saat instance berpartisipasi dalam operasi pengalihan atau failover replika, instance akan menghabiskan waktu sebagai replika baca. PITR dan pemulihan cadangan didukung selama jangka waktu instance digunakan sebagai replika baca dan sebagai instance utama.

Anda dapat melakukan PITR ke waktu sebelum pengalihan saat instance tersebut adalah instance utama. Untuk operasi pengalihan dan failover replika, Cloud SQL memulai pencadangan upaya terbaik untuk instance utama baru segera setelah instance utama baru dipromosikan. PITR diaktifkan pada instance yang dipromosikan hanya setelah pencadangan ini selesai. Pencadangan ini dapat memerlukan waktu 5 hingga 15 menit, bergantung pada ukuran disk.

Cloud SQL melakukan pengaktifan PITR ini secara asinkron, setelah operasi pengalihan atau failover replika selesai, sehingga tidak menambah waktu yang diperlukan operasi.

Split-brain selama failover replika

Split-brain dapat terjadi saat instance utama terus menerima penulisan, sementara replika dipromosikan menggunakan failover replika. Setelah replika dipromosikan, saat instance utama lama tersedia lagi, instance tersebut akan di-build ulang sebagai replika instance yang dipromosikan dan cadangan akhir akan dibuat. Cadangan ini dapat digunakan untuk memulihkan data split-brain yang tidak ditulis ke replika yang dipromosikan.

Penghapusan cadangan dan log transaksi pada replika

Jika instance utama yang diaktifkan dengan PITR dan cadangan menjadi replika baca, kebijakan retensi cadangan dan PITR terakhir dari waktunya sebagai instance utama akan dipertahankan dan diterapkan selama waktunya sebagai replika. Meskipun instance utama baru tidak melakukan pencadangan, cadangan lama dan log transaksi yang digunakan untuk PITR akan dihapus pada replika baca sesuai dengan kebijakan yang terakhir dikonfigurasi.

Misalnya, jika instance dikonfigurasi untuk memiliki pencadangan otomatis harian dan menyimpan 7 cadangan dengan log PITR selama 7 hari, maka saat instance ini menjadi replika baca, apa pun yang berusia lebih dari 7 hari akan dihapus sekali sehari.

Jika perlu menghapus cadangan lebih cepat, Anda dapat menghapus cadangan secara manual. Untuk mengetahui informasi selengkapnya, lihat Menghapus cadangan.

Rekomendasi untuk Kontrol Layanan VPC dan DR lanjutan

Jika Anda menggunakan Kontrol Layanan VPC, pastikan perimeter layanan Anda mengizinkan komunikasi yang diperlukan untuk semua operasi pemulihan seperti operasi pemulihan point-in-time (PITR), terutama saat Anda menggunakan CMEK dengan kunci di project yang berbeda.

Operasi DR lanjutan, seperti pengalihan dan failover replika, dapat mengaktifkan atau mengonfigurasi ulang fitur seperti PITR, yang dapat diblokir oleh Kontrol Layanan VPC jika perimeter layanan tidak dikonfigurasi dengan benar untuk CMEK dan akses kunci lintas project.

  • Pertahankan project kunci KMS dalam perimeter yang sama dengan instance: sebagai praktik terbaik, sertakan project yang berisi kunci KMS dalam perimeter Kontrol Layanan VPC yang sama dengan instance Cloud SQL Anda.
  • Menggunakan perantara perimeter: sebagai opsi sekunder (kurang direkomendasikan), Anda dapat menggunakan perantara perimeter untuk menghubungkan project di perimeter yang berbeda.
  • Pengujian: gunakan mode uji coba Kontrol Layanan VPC untuk menguji prosedur DR Anda (seperti pengalihan) dan mengidentifikasi potensi pelanggaran Kontrol Layanan VPC tanpa penerapan.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Kontrol Layanan VPC.

Batasan

  • Anda tidak dapat menetapkan instance replika baca edisi Cloud SQL Enterprise Plus sebagai replika DR jika instance utama menyimpan log transaksinya untuk pemulihan point-in-time (PITR) di disk. Untuk memeriksa tempat instance menyimpan log-nya untuk PITR, lihat Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR.

  • Anda tidak dapat menetapkan replika eksternal sebagai replika DR.

  • Terraform tidak didukung untuk operasi failover replika.

Memecahkan masalah

Masalah Pemecahan masalah
Operasi pengalihan gagal.
  • Pastikan instance memenuhi semua persyaratan replika DR yang dinyatakan.
  • Periksa volume transaksi di database. Pengalihan mengamankan log biner instance utama di Cloud Storage sebelum melakukan pengalihan. Jika volume transaksi tinggi, operasi mungkin akan mengalami waktu tunggu habis. Pertimbangkan untuk mencoba kembali operasi saat beban transaksi lebih rendah.
Operasi pengalihan gagal dan instance utama terjebak dalam mode hanya baca. Lakukan mulai ulang database untuk mengembalikan instance utama ke mode tulis.
Operasi pengalihan telah selesai, tetapi konsol Google Cloud tidak menampilkan peran baru yang dibalik untuk instance. Muat ulang browser Anda untuk menampilkan topologi yang diperbarui.
Operasi failover replika gagal.
  • Pastikan replika DR ditetapkan untuk instance utama dan sedang online.
  • Jika failover ke replika DR gagal, promosikan ke replika baca reguler (non-DR).
Setelah operasi pengalihan, replika baru gagal direplikasi dengan error "Cannot replicate to server ... because the present server has purged required log biner".

Salah satu penyebab utamanya adalah jika Anda menjalankan perintah administratif tertentu pada replika baca yang mengaktifkan logging biner (seperti replika pemulihan dari bencana (disaster recovery)), MySQL akan meningkatkan GTID replika (gtid_executed) dengan UUID server replika itu sendiri. Setelah operasi pengalihan, saat instance utama sebelumnya menjadi replika baca dari replika DR yang dipromosikan, replikasi akan gagal karena log biner yang berisi transaksi GTID lokal ini telah dihapus permanen.

Untuk mencegah kegagalan replikasi tersebut setelah pengalihan, hindari menjalankan perintah berikut pada replika baca:

  • FLUSH TABLES
  • FLUSH PRIVILEGES
  • REPAIR TABLE TABLE_NAME
  • FLUSH SLOW LOGS
  • FLUSH GENERAL LOGS

Jika Anda harus menjalankan salah satu perintah ini pada replika baca, nonaktifkan logging biner untuk sesi klien sebelum Anda menjalankan perintah:

SET SESSION sql_log_bin = 0;
Tidak dapat mengetahui apakah replikasi tidak terjadi Hubungkan ke replika dan ketik: 
show slave status;
  • Jika replikasi terjadi, kolom pertama "Slave_IO_State" akan menampilkan "Waiting for master to send event" dan kolom "Last_IO_Error" akan kosong.
  • Jika replikasi tidak terjadi, kolom pertama "Slave_IO_State" akan menampilkan "Connecting to master". dan kolom "Last_IO_Error" menampilkan error yang mirip dengan "error connecting to master 'cloudsqlreplica@x.x.x.x:3306".

Anda juga dapat melihat status replikasi untuk replika di dasbor pemantauan Cloud SQL. Untuk mengetahui informasi selengkapnya, lihat Memantau instance Cloud SQL.

Anda menerima pesan error berikut:

"Instance was converted into a replica between the target PITR time and the last available base backup. PITR logs are not available for the period instance was a replica. Please clone from the instance that was primary at time %s"

Anda tidak dapat melakukan PITR untuk jangka waktu saat instance mengalami pengalihan ke replika. Log PITR tidak tersedia untuk jangka waktu saat instance adalah replika.

  • Tinjau daftar operasi untuk instance guna menentukan apakah instance tersebut merupakan replika pada saat itu
  • Gunakan daftar operasi untuk menentukan instance mana yang merupakan instance utama pada waktu tersebut.
  • Buat clone instance tersebut untuk melakukan PITR.

Anda menerima pesan error berikut:

"You can only designate a disaster recovery (DR) replica for primary instances that are storing their PITR logs in Cloud Storage. PITR logs of the instance %s are not stored in Cloud Storage"

Instance utama Anda belum mengalihkan lokasi penyimpanan log transaksinya ke Cloud Storage. Anda dapat mencoba lagi setelah lokasi penyimpanan untuk log transaksi dialihkan, atau Anda dapat mencoba menetapkan replika DR untuk instance utama yang berbeda.

Untuk mengetahui informasi selengkapnya tentang cara memindahkan lokasi penyimpanan log transaksi yang digunakan untuk PITR, lihat Menggunakan pemulihan point-in-time (PITR).

Anda menerima pesan error berikut:

"The specified failover dr replica name REPLICA_NAME must be one of the replicas of the primary instance INSTANCE_NAME."

Untuk mengetahui informasi selengkapnya tentang cara menetapkan replika DR dan sintaksis perintah yang benar, lihat Menetapkan replika DR untuk instance utama.

Langkah berikutnya