Ringkasan indeks replika baca

Dokumen ini menjelaskan konsep dan mekanisme untuk mengelola indeks sekunder di replika baca Cloud SQL di Cloud SQL Enterprise edition dan Cloud SQL Enterprise Plus edition. Di MySQL, Anda dapat membuat dua jenis indeks utama pada tabel:

  • Indeks berkluster: indeks utama pada tabel MySQL yang secara fisik mengurutkan baris pada disk. Ketika Anda menentukan kunci utama pada tabel, MySQL akan menggunakannya sebagai indeks berkluster. Sebuah tabel hanya dapat memiliki satu indeks berkluster.

  • Indeks sekunder: indeks tambahan pada tabel MySQL yang mengoptimalkan performa kueri.

    Meskipun replika biasanya bersifat hanya baca, Anda dapat membuat indeks sekunder pada tabel untuk tujuan pelaporan. Cloud SQL mendukung dua metode untuk membuat indeks sekunder replika:

    • Indeks replika terkelola (Direkomendasikan): Cloud SQL menyimpan definisi indeks pada instance utama dan otomatis membangun ulang indeks sekunder setelah replika mengalami error atau dibuat ulang. Google merekomendasikan indeks terkelola daripada indeks yang dikelola sendiri untuk mencegah hilangnya indeks dan menghindari pemulihan indeks manual.
    • Indeks replika yang dikelola sendiri: memungkinkan Anda menambahkan dan menghapus indeks sekunder langsung di replika, tetapi indeks ini tidak akan dipertahankan setelah replika mengalami error atau pembuatan ulang replika. Jika menggunakan indeks yang dikelola sendiri, Anda dapat bermigrasi untuk menggunakan indeks replika terkelola.

Membandingkan metode indeks replika

Tabel berikut membandingkan indeks replika terkelola dan indeks replika yang dikelola sendiri di Cloud SQL:

Fitur Indeks replika terkelola Indeks replika yang dikelola sendiri
Persistensi di seluruh pembuatan ulang replika Dibuat ulang secara otomatis Dihapus (perlu dibuat ulang secara manual)
Model konfigurasi Metadata terpusat di instance utama DDL langsung pada replika baca target
Mekanisme eksekusi Proses latar belakang berkala
(kira-kira setiap lima menit)		 Eksekusi langsung
Pedoman jeda replikasi Menjeda pembuatan indeks secara otomatis jika jeda replikasi melebihi 20 menit Tidak ada (dikelola pengguna)
Edisi yang didukung Edisi Cloud SQL Enterprise dan edisi Cloud SQL Enterprise Plus Edisi Cloud SQL Enterprise dan edisi Cloud SQL Enterprise Plus
Versi database yang didukung Cloud SQL untuk MySQL
(versi pemeliharaan R20260726.00_05 atau yang lebih baru)		 Cloud SQL untuk MySQL
(semua versi yang didukung)
Dukungan replika server eksternal Tidak didukung Didukung

Indeks replika terkelola

Untuk mencegah hilangnya indeks setelah pembuatan ulang replika, Cloud SQL mendukung indeks replika terkelola. Google merekomendasikan metode pembuatan dan retensi indeks ini. Cloud SQL mengaktifkan metode ini secara default.

Indeks replika terkelola memerlukan versi pemeliharaan Cloud SQL R20260726.00_05 atau yang lebih baru.

Bagian berikut menjelaskan cara Cloud SQL mengelola indeks replika, manfaatnya, dan perilakunya selama peristiwa siklus proses.

Cara Cloud SQL mengelola indeks replika terkelola

Dengan metode ini, Anda menentukan indeks sekunder replika, mengelompokkannya, dan menentukan replika mana yang dapat mempertahankan grup indeks tersebut. Cloud SQL menjalankan proses latar belakang pada replika untuk membuat dan menghapus indeks yang diperlukan secara otomatis dan mempertahankan indeks dari waktu ke waktu. Saat Cloud SQL membuat indeks replika terkelola, Cloud SQL akan menambahkan tag [SIC_X_Y] ke komentar indeks, dengan X dan Y adalah bilangan bulat. Tag ini hanya digunakan untuk pengelolaan internal dan tidak memiliki fungsi.

Cloud SQL melakukan pemeliharaan indeks replika terkelola, seperti membuat dan menghapus indeks, dalam batch. Setelah proses pemeliharaan indeks Cloud SQL mengambil sekelompok tindakan CREATE atau DROP, proses ini akan membuat entri status PENDING untuk setiap indeks sekunder. Kemudian, alat ini akan menjalankan setiap pernyataan bahasa definisi data (DDL) secara serial. Kegagalan pada satu indeks tidak memblokir eksekusi indeks berikutnya dalam antrean. Cloud SQL kemudian mengambil batch berikutnya setelah sekitar lima menit.

Manfaat dan kasus penggunaan

Indeks replika terkelola memberikan manfaat berikut:

  • Retensi indeks otomatis: saat Cloud SQL membuat ulang replika baca (seperti setelah instance error), Cloud SQL akan otomatis membangun ulang indeks sekunder yang dipetakan ke replika tersebut. Anda tidak perlu menjalankan prosedur tersimpan manual atau mengelola skrip pelacakan skema eksternal untuk memulihkan indeks yang hilang.
  • Performa kueri yang konsisten: dengan otomatis membangun ulang indeks sekunder setelah pemulihan replika, Cloud SQL mempertahankan throughput kueri dan mencegah lonjakan latensi kueri serta pemakaian CPU yang tinggi yang disebabkan oleh kueri yang tidak diindeks.
  • Konfigurasi berbasis grup: Anda menentukan indeks sekunder sekali pada instance utama dan mengaturnya ke dalam grup replika bernama. Kemudian, Anda dapat menetapkan grup indeks yang berisi ratusan indeks ke replika baca dengan menetapkan satu flag database (cloudsql_index_recreate_replica_group). Hal ini menghilangkan kebutuhan untuk menjalankan prosedur tersimpan satu per satu di beberapa replika.
  • Penetapan indeks selektif berdasarkan peran replika: Anda dapat menetapkan grup indeks khusus untuk replika baca pelaporan dan analisis guna mempercepat kueri baca, sekaligus menjaga replika baca disaster recovery (DR) tidak diindeks dan identik dengan skema instance utama. Hal ini mencegah overhead transaksi tulis dan jeda replikasi pada instance DR.
  • Isolasi performa instance utama: indeks sekunder pada replika baca mengoptimalkan kueri baca dan pelaporan tanpa menggunakan penyimpanan atau menambahkan latensi transaksi tulis ke instance utama.
  • Kemampuan observasi bawaan: prosedur tersimpan khusus memungkinkan Anda memantau progres pembuatan indeks, durasi eksekusi, dan log error pada replika baca.
  • Migrasi dan koeksistensi tanpa gangguan: indeks replika terkelola dapat berdampingan dengan aman dengan indeks replika yang dikelola sendiri yang ada pada instance dan tabel yang sama. Anda dapat mengadopsi indeks replika terkelola secara bertahap tanpa periode nonaktif, atau mengganggu workload kueri baca yang aktif.

Promosi replika

Cloud SQL mengelola indeks replika terkelola hanya pada instance replika baca. Jika Anda mempromosikan replika baca ke instance utama, Cloud SQL akan otomatis menghapus indeks sekunder yang dibuat sebagai indeks replika terkelola. Penundaan sekitar lima menit dapat terjadi sebelum Cloud SQL menjalankan penghapusan.

Meskipun Cloud SQL menghapus indeks sekunder dan menghapus flag database dari instance yang dipromosikan, instance utama mempertahankan definisi indeks sekunder dan pemetaan grup.

Pengalihan disaster recovery (DR)

Selama peralihan DR, saat Anda mempromosikan replika DR ke instance utama baru, Cloud SQL akan otomatis menghapus semua indeks sekunder yang dibuat di replika DR. Cloud SQL tidak otomatis membuat indeks sekunder ini di instance utama lama saat instance tersebut menjadi replika.

Untuk membuat indeks sekunder pada instance utama lama setelah pengalihan, tetapkan flag database cloudsql_index_recreate_replica_group pada instance tersebut.

Jeda replikasi

Cloud SQL menjeda operasi pembuatan indeks sekunder jika jeda replikasi melebihi 20 menit. Jika pembuatan indeks replika terkelola sudah berlangsung saat jeda melebihi 20 menit, Cloud SQL akan membiarkan operasi selesai. Kelambatan replikasi tidak menjeda operasi penghapusan indeks replika terkelola.

Batasan

Saat Anda menggunakan indeks replika terkelola, batasan berikut berlaku:

  • Anda tidak dapat membuat indeks replika terkelola di replika server eksternal: Cloud SQL tidak mendukung pembuatan indeks replika terkelola untuk replika server eksternal.
  • Maksimum 1.000 indeks per grup replika: Anda dapat menetapkan maksimum 1.000 indeks sekunder ke grup replika.
  • Memperbarui atau mengubah metadata indeks tidak didukung: Anda tidak dapat memperbarui atau mengubah metadata indeks yang ada. Untuk mengubah indeks, Anda harus menghapus definisi indeks yang ada dan membuat yang baru.

Indeks replika yang dikelola sendiri

Indeks replika yang dikelola sendiri adalah indeks sekunder yang Anda buat dan hapus langsung pada setiap replika baca Cloud SQL. Seperti indeks replika terkelola, indeks ini mengoptimalkan performa kueri baca—seperti untuk workload pelaporan dan analisis—tanpa menggunakan penyimpanan atau memengaruhi latensi tulis pada instance utama.

Pengelolaan indeks yang dikelola sendiri

Anda mengelola indeks replika yang dikelola sendiri langsung di replika baca menggunakan prosedur tersimpan berikut dalam skema mysql:

  • mysql.addSecondaryIdxOnReplica: menambahkan indeks sekunder pada tabel yang ditentukan di replika baca. Prosedur tersimpan ini adalah wrapper untuk pernyataan DDL CREATE INDEX.
  • mysql.dropSecondaryIdxOnReplica: menghapus indeks sekunder yang dibuat sebelumnya dari replika baca. Prosedur tersimpan ini adalah wrapper untuk pernyataan DDL DROP INDEX.

Menjalankan prosedur tersimpan ini memerlukan peran cloudsqlsuperuser.

Saat Anda membuat indeks yang dikelola sendiri, Cloud SQL mencatat metadata dasar dalam tabel mysql.cloudsql_replica_index pada replika, termasuk nama database, nama tabel, dan nama indeks. Tidak seperti indeks replika terkelola, indeks yang dikelola sendiri tidak terdaftar di instance utama dan tidak dikelola oleh proses replikasi latar belakang Cloud SQL.

Untuk mengetahui detail sintaksis dan contoh penggunaan, lihat Indeks replika yang dikelola sendiri.

Manfaat dan kasus penggunaan

Indeks replika yang dikelola sendiri memberikan manfaat berikut untuk alur kerja tertentu:

  • Isolasi performa instance utama: indeks sekunder pada replika baca mengoptimalkan kueri baca dan pelaporan tanpa menggunakan penyimpanan atau menambahkan latensi transaksi tulis ke instance utama.
  • Eksekusi langsung: panggilan prosedur tersimpan langsung dieksekusi sebagai pernyataan DDL pada replika, tanpa menunggu siklus pemeliharaan latar belakang berkala (sekitar setiap lima menit) yang diperlukan oleh indeks replika terkelola.
  • Pengujian dan eksperimen terisolasi: Anda dapat menguji performa kueri dan memvalidasi pengoptimalan indeks pada setiap replika baca sebelum membuat indeks replika terkelola di seluruh grup replika.

Batasan

Indeks replika yang dikelola sendiri memiliki batasan operasional yang signifikan:

  • Kurangnya persistensi di seluruh pembuatan ulang replika: jika Cloud SQL membuat ulang replika baca (seperti selama pemulihan instance, pemeliharaan, atau kegagalan hardware), semua indeks sekunder yang dikelola sendiri pada replika tersebut akan dihapus dan tidak dipulihkan secara otomatis.
  • Overhead pemulihan manual: Cloud SQL tidak dapat merekonstruksi dan membangun ulang indeks. Anda harus membuat ulang indeks secara manual dengan menjalankan mysql.addSecondaryIdxOnReplica lagi.
  • Penurunan performa kueri: kueri baca mungkin mengalami penurunan performa setelah pembuatan ulang replika hingga Anda membuat ulang indeks yang hilang secara manual.

Karena indeks replika terkelola otomatis dipertahankan dan dibuat ulang di seluruh peristiwa pembuatan ulang replika, Google merekomendasikan penggunaan indeks replika terkelola untuk workload produksi. Jika Anda sudah memiliki indeks yang dikelola sendiri, migrasikan indeks tersebut ke indeks replika terkelola.

Koeksistensi jenis indeks replika

Indeks replika yang dikelola sendiri (dibuat menggunakan mysql.addSecondaryIdxOnReplica) dan indeks replika terkelola dapat berdampingan di instance replika baca Cloud SQL yang sama dan di tabel yang sama. Dengan demikian, Anda dapat mengadopsi indeks replika terkelola secara bertahap tanpa mengganggu workload database yang ada.

Saat Anda menggunakan kedua metode pengelolaan indeks, pertimbangkan perilaku berikut:

  • Operasi independen: indeks yang dikelola sendiri yang Anda buat langsung di replika baca akan terus berfungsi bersama indeks replika terkelola.
  • Evaluasi berkala: proses pemeliharaan latar belakang Cloud SQL secara berkala (sekitar setiap lima menit) mengevaluasi definisi indeks yang dipetakan ke grup replika yang Anda tetapkan ke replika.
  • Penanganan konflik nama: jika Anda mendaftarkan definisi indeks replika terkelola dengan nama yang sama dengan indeks yang dikelola sendiri yang sudah ada di replika baca, proses latar belakang akan mendeteksi bahwa indeks dengan nama tersebut sudah ada. Proses ini mencatat status FAILED dalam tabel mysql.cloudsql_replica_idx_status. Error ini tidak memengaruhi traffic database, membuat kunci tabel, atau memengaruhi indeks yang dikelola sendiri yang ada.
  • Penyelesaian otomatis setelah pembuatan ulang: saat replika baca dibuat ulang, Cloud SQL akan menghapus indeks yang dikelola sendiri yang ada sebagai bagian dari pembuatan ulang instance dan secara otomatis membuat indeks replika terkelola dari definisi yang terdaftar.

Langkah berikutnya