Melakukan penggantian ke MySQL

Panduan ini menjelaskan cara melakukan penggantian dan rollback pemulihan dari bencana dari Spanner kembali ke instance MySQL sumber Anda.

Jika Anda mengalami penurunan performa yang tidak terduga, error aplikasi yang tidak dapat dipulihkan, atau pemblokir fungsional penting setelah beralih ke Spanner, gunakan prosedur di bagian berikut untuk melakukan roll back ke instance utama MySQL:

Sebelum memulai

Sebelum memulai prosedur penggantian, verifikasi prasyarat berikut:

1. Replikasi terbalik aktif: Pastikan pipeline Dataflow replikasi terbalik (Spanner_to_SourceDb) berjalan dan secara aktif menggunakan aliran perubahan Spanner dalam mode pemfilteran forward_migration. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi penggantian ke MySQL.
2. Ketersediaan MySQL sumber: Pastikan database MySQL sumber Anda online, dapat dijangkau dari Dataflow, dan dapat menerima koneksi tulis.
3. Masa pemeliharaan: Beri tahu pemangku kepentingan bahwa periode nonaktif yang direncanakan diperlukan saat penulisan Spanner dijeda dan replikasi balik dikosongkan.

Peran yang diperlukan

• Untuk mendapatkan izin yang Anda perlukan untuk melakukan penggantian ke MySQL, minta administrator untuk memberi Anda peran IAM berikut pada project:

  • Cloud Spanner Database User (roles/spanner.databaseUser)
  • Dataflow Admin (roles/dataflow.admin)
  • Datastream Admin (roles/datastream.admin)
  • Storage Admin (roles/storage.admin)
  • Monitoring Viewer (roles/monitoring.viewer)
  • Pelihat (roles/viewer)

Menjeda penulisan Spanner

Peringatan: Waktu istirahat aplikasi dimulai pada langkah ini.

1. Jeda semua traffic penulisan database ke Spanner di aplikasi Anda.
2. Izinkan transaksi aktif di Spanner untuk di-commit dan dikosongkan sepenuhnya.

Mengizinkan replikasi terbalik untuk mengosongkan

Bagian berikut menjelaskan cara memverifikasi bahwa semua perubahan yang ditulis ke Spanner setelah pengalihan direplikasi kembali ke MySQL sebelum mengalihkan penulisan aplikasi.

Memantau jeda replikasi

Lacak jeda replikasi untuk memverifikasi bahwa semua perubahan dalam proses ditulis ke MySQL:

1. Di konsol Google Cloud , buka halaman Job details untuk tugas Dataflow replikasi terbalik Anda.
2. Di tab Metrik kustom, periksa penghitung pengguna replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi penggantian ke MySQL.
3. Tunggu hingga nilai penghitung mencapai 0.

Atau, di Metrics Explorer, buat kueri penghitung pengguna menggunakan Monitoring Query Language (MQL):

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
    

Ganti kode berikut: * JOB_ID: ID tugas Dataflow replikasi balik Anda. * LOGICAL_SHARD_NAME: nama shard logis yang dikonfigurasi untuk database sumber Anda.

Memverifikasi aktivitas tulis MySQL

Pastikan operasi penulisan replikasi terbalik telah selesai di database sumber Anda:

1. Di database utama MySQL sumber, periksa kueri aktif dan metrik koneksi database.
2. Pastikan traffic tulis dari pipeline replikasi terbalik telah berhenti.

Memverifikasi status DLQ yang bersih

Periksa antrean pesan yang tidak diproses (DLQ) untuk memastikan tidak ada error yang tidak tertangani yang terjadi selama replikasi terbalik:

1. Di konsol Google Cloud , buka halaman Job details untuk tugas Dataflow replikasi terbalik Anda. Di tab Metrik kustom, periksa penghitung pengguna severe_error_count.

2. Periksa direktori DLQ replikasi balik yang parah dan coba lagi di Cloud Storage (misalnya, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ dan gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/).

   Anda dapat mencantumkan konten direktori DLQ parah menggunakan gcloud CLI:

   gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/
   

   Ganti kode berikut:

   • MIGRATION_BUCKET: nama bucket Cloud Storage Anda.
   • ENV: nama lingkungan deployment Anda (misalnya, prod).
   • SERVICE: nama aplikasi atau layanan Anda.
   • DB_SCHEMA: nama skema database Anda.

3. Pastikan direktori DLQ tetap kosong sepenuhnya.

4. Jika file error ada, selesaikan masalah yang mendasarinya dan putar ulang rekaman yang gagal sebelum melanjutkan. Untuk mengetahui informasi selengkapnya, lihat Memantau dan menyelesaikan error replikasi terbalik.

Melanjutkan streaming CDC forward

Jika Anda berencana melanjutkan migrasi ke depan ke Spanner pada masa mendatang, lanjutkan aliran Datastream ke depan:

1. Di konsol Google Cloud , buka halaman Detail streaming untuk streaming Anda.
2. Klik Lanjutkan, dan tunggu hingga status aliran data berubah menjadi RUNNING. Untuk mengetahui informasi selengkapnya, lihat Memigrasikan data MySQL.

Atau, untuk melanjutkan streaming menggunakan gcloud CLI, jalankan perintah gcloud datastream streams resume:

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

Ganti kode berikut:

• STREAM_ID: ID streaming Datastream Anda.
• LOCATION: region Google Cloud tempat aliran data Anda berada.

Mengalihkan penulisan ke MySQL

Catatan: Periode nonaktif aplikasi berakhir pada langkah ini.

1. Perbarui konfigurasi aplikasi dan string koneksi database untuk menargetkan instance database utama MySQL sumber Anda.
2. Mulai layanan aplikasi dan lanjutkan traffic baca dan tulis langsung terhadap MySQL.
3. Pastikan operasi baca dan tulis aplikasi berjalan dengan baik pada database MySQL.

Langkah berikutnya

• Melakukan peralihan dari MySQL
• Mengonfigurasi penggantian ke MySQL
• Bermigrasi dari MySQL ke Spanner