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. Untuk Cloud SQL untuk SQL Server, replika DR adalah replika yang dapat di-cascade.
  • 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.

Membuat replika DR

Sebelum menggunakan DR lanjutan, buat replika bertingkat dari instance utama di region yang berbeda dengan instance utama.

Melakukan peralihan

Setelah membuat 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. Pencadangan ini dapat memerlukan waktu antara 5 hingga 15 menit untuk diselesaikan, bergantung pada ukuran disk. Setelah pencadangan ini selesai, jika Anda ingin menggunakan PITR pada instance yang dipromosikan, Anda harus mengaktifkan PITR secara manual. 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:

  • Jika Anda belum melakukannya, buat replika DR.
  • Gunakan prosedur tersimpan sp_help_revlogin untuk mentransfer login SQL Server yang dibuat di instance utama setelah replika DR dibuat. Menyinkronkan login memastikan bahwa aplikasi dapat segera terhubung kembali setelah operasi pengalihan selesai.
  • 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

gcloud

Untuk melakukan operasi pengalihan, jalankan perintah berikut:

gcloud sql instances switchover REPLICA_NAME

Ganti variabel berikut:

  • REPLICA_NAME: nama replika DR yang perannya ingin Anda tukar dengan instance utama.

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.

resource "google_sql_database_instance" "original-primary" {
  name             = "sqlserver-primary-instance-name"
  region           = "us-east1"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  instance_type    = "CLOUD_SQL_INSTANCE"
  root_password    = "INSERT-PASSWORD-HERE"
  replica_names    = ["sqlserver-replica-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name = "sqlserver-replica-instance-name"
  # Remove or comment out the master_instance_name
  # master_instance_name = google_sql_database_instance.original-primary.name
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  # Remove or comment out the replica_configuration section
  # replica_configuration {
  #  cascadable_replica = true
  # }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

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.

resource "google_sql_database_instance" "original-primary" {
  name = "sqlserver-primary-instance-name"
  # Set master_instance_name to the new primary instance, the original DR replica.
  master_instance_name = "sqlserver-replica-instance-name"
  region               = "us-east1"
  database_version     = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Remove  values from the replica_names field, but don't remove the field itself.
  replica_names = []
  # Add replica_configuration section and set cascadable_replica to true.
  replica_configuration {
    cascadable_replica = true
  }
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name             = "sqlserver-replica-instance-name"
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

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 dari project Google Cloud 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. 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.

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, buat replika DR.
  • Jika instance utama masih dapat diakses, gunakan prosedur tersimpan sp_help_revlogin untuk mentransfer login SQL Server yang tidak disinkronkan ke replika DR. Menyinkronkan login secara rutin memastikan bahwa aplikasi dapat segera terhubung kembali setelah failover.
  • Pastikan replika DR online dan responsif.

Melakukan operasi failover replika

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 SQL Server 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

Baik pengalihan maupun failover replika, jika replika DR dipromosikan menjadi instance utama, dan Anda ingin menggunakan PITR pada instance yang dipromosikan, Anda harus mengaktifkan PITR secara manual.

Setelah PITR diaktifkan, kebijakan retensi log transaksi dan konfigurasi cadangan akan berlaku. Jika Anda tidak menentukan nilai untuk setelan ini, nilai default 14 hari akan berlaku.

Untuk mengetahui informasi selengkapnya, lihat Menggunakan PITR.

Setelah PITR diaktifkan pada instance utama baru, Anda dapat memulihkan instance ke titik waktu mana pun selama instance tersebut menjadi instance utama yang aktif.

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.

  • Simpan project kunci KMS di perimeter yang sama dengan instance: sebagai praktik terbaik, sertakan project yang berisi kunci KMS di 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.

  • Anda tidak dapat menggunakan konsol Google Cloud untuk melakukan operasi failover atau pengalihan replika.

Memecahkan masalah

Masalah Pemecahan masalah
Operasi pengalihan gagal.
    Pastikan instance memenuhi semua persyaratan replika DR (replika bertingkat) yang dinyatakan.
  • Periksa volume transaksi di database. 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 Anda telah membuat replika DR untuk instance utama dan replika DR tersebut sedang online.
  • Jika failover ke replika DR gagal, promosikan ke replika baca reguler (non-DR).

Langkah berikutnya