Melakukan peralihan dari MySQL

Panduan ini menjelaskan cara melakukan cutover migrasi database aktif dari instance sumber MySQL ke database Spanner menggunakan Datastream dan Dataflow.

Catatan: Prosedur cutover yang dijelaskan dalam panduan ini memerlukan periode nonaktif aplikasi yang direncanakan. Selama periode ini, jeda semua operasi tulis database aplikasi untuk memungkinkan perubahan yang sedang berlangsung dikosongkan dan dikonvergensi sepenuhnya sebelum mengalihkan koneksi aplikasi ke Spanner.

Sebelum memulai

Sebelum melakukan cutover, pastikan Anda telah menyelesaikan tugas berikut sebagai bagian dari migrasi data aktif:

1. Migrasi skema: Deploy skema Anda ke Spanner. Untuk mengetahui informasi selengkapnya, lihat Memigrasikan skema dari MySQL.
2. Migrasi backfill: Selesaikan migrasi data awal menggunakan tugas Dataflow migrasi backfill. Untuk mengetahui informasi selengkapnya, lihat Melakukan migrasi backfill.
3. Replikasi CDC aktif: Pastikan replikasi pengambilan data perubahan (CDC) berkelanjutan aktif dan sehat:
   • Aliran Datastream secara aktif membaca peristiwa perubahan dari database MySQL sumber dan menuliskannya ke bucket Cloud Storage.
   • Notifikasi bucket Cloud Storage memublikasikan peristiwa pembuatan objek ke topik Pub/Sub.
   • Tugas Dataflow streaming (Cloud_Datastream_to_Spanner) menggunakan langganan Pub/Sub dan menulis perubahan ke Spanner dengan latensi replikasi sub-detik atau dapat diabaikan. Untuk mengetahui informasi selengkapnya, lihat Memigrasikan data MySQL.
4. Validasi data awal: Jalankan pemeriksaan validasi data untuk memverifikasi konsistensi data antara instance MySQL sumber dan target Spanner. Untuk mengetahui informasi selengkapnya, lihat Memvalidasi migrasi data.
5. Status dead-letter queue (DLQ) yang bersih: Pastikan direktori DLQ parah replikasi penerusan di Cloud Storage (misalnya, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) benar-benar kosong. Jika ada error parah, selesaikan masalah yang mendasarinya dan putar ulang semua peristiwa perubahan yang gagal menggunakan tugas batch retryDLQ sebelum memulai cutover. Untuk mengetahui informasi selengkapnya, lihat Memantau dan mengatasi error DLQ CDC error.
6. Penyiapan replikasi terbalik (Kesiapan penggantian): Jika Anda memerlukan jalur penggantian kontingensi, siapkan pipeline replikasi terbalik aktif dari Spanner kembali ke database MySQL sumber. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi penggantian ke MySQL.

Peran yang diperlukan

• Untuk mendapatkan izin yang Anda perlukan untuk melakukan cutover, minta administrator Anda untuk memberi Anda peran IAM berikut di project:

  • Pengguna Database Cloud Spanner (roles/spanner.databaseUser)
  • Admin Dataflow (roles/dataflow.admin)
  • Admin Datastream (roles/datastream.admin)
  • Admin Penyimpanan (roles/storage.admin)
  • Monitoring Viewer (roles/monitoring.viewer)
  • Pub/Sub Viewer (roles/pubsub.viewer)
  • Viewer (roles/viewer)

Melakukan cutover

Bagian berikut menjelaskan cara mengosongkan pipeline tulis dan memverifikasi bahwa semua perubahan sumber direplikasi ke Spanner sebelum mengalihkan penulisan aplikasi.

Memverifikasi status DLQ dan kesehatan pipeline

Sebelum menjeda traffic tulis aplikasi atau memulai waktu nonaktif, pastikan pipeline replikasi penerusan Anda tidak memiliki peristiwa perubahan yang terdampar di DLQ-nya:

1. Di Google Cloud konsol, buka halaman detail Job untuk pipeline Dataflow streaming Anda.
2. Di tab Metrik kustom, periksa penghitung kustom Total permanent errors.

3. Jika penghitung ini lebih besar dari 0, periksa direktori DLQ parah Cloud Storage Anda (misalnya, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) dan pastikan direktori tersebut kosong.

   Catatan: Penghitung Total permanent errors bersifat kumulatif dan tidak berkurang saat data dicoba lagi. Jika ada file error di direktori DLQ Anda, jangan lanjutkan cutover. Untuk mengetahui informasi selengkapnya tentang cara mengatasi error dan memutar ulang data menggunakan tugas batch retryDLQ, lihat [Memantau dan mengatasi error DLQ CDC](/spanner/docs/mysql-live-data-migration#resolve-cdc-dlq-errors).

Menjeda penulisan aplikasi

Peringatan: Waktu nonaktif aplikasi dimulai pada langkah ini.

1. Jeda semua traffic tulis database di aplikasi Anda.
2. Izinkan transaksi aktif pada instance utama MySQL sumber untuk melakukan commit dan mengosongkan sepenuhnya.

Melacak dan menjeda Datastream

1. Di Google Cloud konsol, buka halaman Stream details untuk aliran Anda.
2. Di tab Monitoring, periksa diagram keaktualan data (jenis metrik Cloud Monitoring: datastream.googleapis.com/stream/freshness). Tunggu hingga nilai metrik menurun menjadi 0. Hal ini menunjukkan bahwa Datastream mengambil dan memproses semua perubahan database sumber hingga saat penulisan dijeda. Untuk mengetahui informasi selengkapnya, lihat Memantau aliran.

3. Pastikan tidak ada peristiwa replikasi yang melewati aliran. Di tab Monitoring, periksa diagram Throughput (jenis metrik Monitoring: datastream.googleapis.com/stream/event_count) dan pastikan kecepatan peristiwa adalah 0.

   Atau, untuk memverifikasi secara terprogram menggunakan Metrics Explorer, kueri jumlah peristiwa menggunakan Monitoring Query Language (MQL):

   fetch datastream.googleapis.com/Stream
   | metric 'datastream.googleapis.com/stream/event_count'
   | filter (resource.stream_id == 'STREAM_ID')
   | align rate(1m)
   | group_by [], [value_event_count_sum: sum(value.event_count)]
   | every 1m

   Ganti STREAM_ID dengan ID aliran Anda.

   Pastikan metrik ini melaporkan 0 untuk setidaknya dua periode agregasi berturut-turut.

4. Jeda aliran Datastream Anda menggunakan Google Cloud konsol atau API, dan tunggu hingga status aliran berubah menjadi PAUSED.

Menunggu data perubahan yang sedang berlangsung untuk dikosongkan

1. Di Google Cloud konsol, buka halaman Stream details untuk aliran Anda.
2. Di tab Monitoring, periksa diagram System latency (jenis metrik Monitoring: datastream.googleapis.com/stream/system_latencies).
3. Perhatikan nilai latensi persentil ke-99 (P99) dan tunggu setidaknya dua kali latensi sistem P99 ditambah 30 detik setelah menjeda aliran Anda. Periode tunggu ini membantu memastikan bahwa semua file data perubahan yang dibuat sebelum dijeda ditulis dengan aman ke Cloud Storage dan peristiwa pembuatan objeknya dipublikasikan ke Pub/Sub.
4. Pastikan tugas Dataflow streaming Anda menggunakan semua peristiwa perubahan yang tertunda. Di Google Cloud konsol, buka halaman Subscriptions Pub/Sub, lalu pilih langganan yang dibuat selama penyiapan migrasi CDC Anda.
5. Di tab Monitoring, periksa diagram Unacknowledged message count (jenis metrik Monitoring: pubsub.googleapis.com/subscription/num_undelivered_messages) dan pastikan jumlahnya adalah 0.

Memastikan replikasi selesai

1. Pastikan pipeline Dataflow streaming Anda selesai menulis semua perubahan yang direplikasi. Di halaman Job details untuk tugas streaming Anda, pilih tab Custom metrics, lalu periksa penghitung pengguna Replication lag total latency_MAX. Tunggu hingga nilai penghitung mencapai 0.

   Atau, di Metrics Explorer, kueri penghitung pengguna menggunakan MQL:

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

   Ganti JOB_ID dengan ID tugas Dataflow Anda.

2. Pastikan aktivitas tulis berhenti di database Spanner target. Di halaman Database details untuk database target Anda, pilih tab Monitoring dan periksa diagram Write throughput (jenis metrik Monitoring: spanner.googleapis.com/transaction_stat/total/bytes_written_count). Pastikan throughput tulis adalah 0 untuk setidaknya dua periode agregasi 1 menit berturut-turut.

3. Lakukan pemeriksaan akhir DLQ replikasi penerusan Anda. Periksa direktori DLQ parah dan coba lagi di Cloud Storage (misalnya, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ dan gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/) untuk memastikan direktori tersebut tetap kosong.

4. Kosongkan tugas Dataflow streaming Anda:

   1. Di Google Cloud konsol, buka halaman Job details untuk tugas streaming Anda.
   2. Klik Stop job, pilih Drain, lalu klik Stop job.
   3. Tunggu hingga status tugas berubah menjadi Drained. Untuk mengetahui informasi selengkapnya, lihat Menghentikan pipeline yang sedang berjalan.

5. Lakukan verifikasi DLQ pasca-pengosongan: Setelah status tugas berubah menjadi Drained, periksa direktori DLQ parah dan coba lagi di Cloud Storage untuk terakhir kalinya. Pastikan tidak ada file error baru yang muncul saat data yang sedang berlangsung dikosongkan. Jika ada file, selesaikan dan putar ulang. Untuk mengetahui informasi selengkapnya, lihat Memantau dan mengatasi error DLQ CDC.

Melakukan cutover aplikasi

Catatan: Waktu nonaktif aplikasi berakhir pada langkah ini.

Alihkan koneksi database aplikasi ke Spanner dan lanjutkan traffic baca dan tulis aktif:

1. Perbarui konfigurasi aplikasi atau string koneksi database untuk menargetkan database Spanner Anda.
2. Mulai layanan aplikasi dan pastikan traffic baca dan tulis aktif berjalan dengan sukses terhadap Spanner.
3. Pantau pipeline replikasi terbalik Anda untuk mengetahui error. Jika penulisan Spanner gagal direplikasi kembali ke MySQL, Dataflow akan menyimpan data yang gagal ke direktori DLQ di Cloud Storage (misalnya, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/). Periksa jalur ini secara berkala untuk memastikan jalur tersebut tetap kosong. Jika data yang gagal muncul, lihat Memantau dan mengatasi error replikasi terbalik.

Langkah berikutnya

• Mengonfigurasi penggantian ke MySQL
• Melakukan penggantian ke MySQL
• Memigrasikan data MySQL
• Bermigrasi dari MySQL ke Spanner