Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Mengonfigurasi penggantian ke MySQL

Dokumen ini menjelaskan cara mengonfigurasi failover untuk MySQL menggunakan replikasi terbalik. Failover mengacu pada rencana kontingensi untuk kembali ke database MySQL sumber jika Anda mengalami masalah dengan Spanner.

Replikasi terbalik berguna saat Anda mengalami masalah yang tidak terduga dan perlu melakukan failover ke database MySQL asli dengan gangguan minimal pada layanan. Replikasi terbalik memungkinkan Anda melakukan failover dengan mereplikasi data yang ditulis ke Spanner di database MySQL sumber.

Alur replikasi terbalik melibatkan langkah-langkah berikut, yang dilakukan oleh template Dataflow Spanner_to_SourceDb:

Membaca perubahan dari Spanner menggunakan aliran perubahan Spanner.
Memfilter data menggunakan mode filtrasi forward_migration.
Mengubah data Spanner agar kompatibel dengan skema database sumber menggunakan alat migrasi Spanner. Untuk mengetahui informasi selengkapnya, lihat Transformasi kustom.
Memverifikasi apakah database MySQL sumber sudah berisi data yang lebih baru untuk kunci utama yang ditentukan. Jika data yang lebih baru sudah ada, pipeline akan melewati peristiwa perubahan untuk menghindari penimpaan data yang lebih baru.
Menulis data ke database sumber.

Menggunakan template Dataflow `Spanner_to_SourceDb`

Template Dataflow membantu memastikan konsistensi di tingkat kunci utama. Template ini membuat tabel metadata, yang dikenal sebagai tabel bayangan, di Spanner yang berisi stempel waktu commit transaksi tulis terakhir pada shard untuk tabel tertentu tersebut.

Penulisan konsisten hingga stempel waktu commit kunci utama.

Replikasi terbalik berjalan sebagai tugas Dataflow streaming berkelanjutan. Tugas ini membaca peristiwa perubahan dari aliran perubahan Spanner, mengonversinya ke jenis data yang kompatibel dengan skema database sumber, dan menuliskannya ke database MySQL Anda. Jika suatu peristiwa mengalami error sementara, tugas akan otomatis mencoba ulang melalui direktori antrean pesan yang tidak terkirim (DLQ) retry/ di Cloud Storage. Jika suatu peristiwa mengalami error permanen (atau melebihi upaya percobaan ulang), tugas akan merutekannya ke direktori DLQ severe/ untuk penyelesaian manual. Untuk mengetahui informasi selengkapnya tentang cara mengatasi dan memutar ulang data yang gagal, lihat Memantau dan mengatasi error replikasi terbalik errors.

Sebelum memulai

Verifikasi konektivitas jaringan antara database MySQL sumber dan Google Cloud project Anda, tempat tugas Dataflow Anda berjalan.
Buat daftar yang diizinkan untuk alamat IP worker Dataflow di instance MySQL sumber.
Pastikan kredensial MySQL ditentukan dengan benar dalam source shards file.
Pastikan instance MySQL Anda online dan berjalan.
Pastikan pengguna MySQL memiliki hak istimewa INSERT, UPDATE, dan DELETE di database MySQL.
Pastikan Anda memiliki izin IAM yang diperlukan untuk menjalankan template fleksibel Dataflow. Untuk mengetahui informasi selengkapnya, lihat Membangun dan menjalankan template fleksibel.
Pastikan port 12345 terbuka untuk komunikasi antara VM worker Dataflow.

Peran yang diperlukan

Untuk mendapatkan izin yang diperlukan untuk meluncurkan replikasi terbalik, minta administrator Anda untuk memberi Anda peran IAM berikut di instance:
- Pengguna Database Cloud Spanner (roles/spanner.databaseUser)
- Developer Dataflow (roles/dataflow.developer)

Untuk memastikan bahwa akun layanan Compute Engine memiliki izin yang diperlukan untuk meluncurkan replikasi terbalik, minta administrator Anda untuk memberikan peran IAM berikut ke akun layanan Compute Engine di instance:

Penting: Anda harus memberikan peran ini ke akun layanan Compute Engine, bukan ke akun pengguna Anda. Kegagalan memberikan peran ke principal yang benar dapat menyebabkan error izin.
- Pengguna Database Cloud Spanner (roles/spanner.databaseUser)
- Secret Manager Secret Accessor (roles/secretmanager.secretAccessor)
- Secret Manager Viewer (roles/secretmanager.viewer)

Menjalankan replikasi terbalik

Untuk menjalankan replikasi terbalik, ikuti langkah-langkah berikut:

Upload file sesi ke bucket Cloud Storage.
Buat notifikasi Pub/Sub untuk folder retry direktori DLQ. Anda dapat melakukannya dengan membuat topik Pub/Sub dan langganan Pub/Sub untuk topik tersebut.
Buat dan siapkan template Dataflow. Untuk mengetahui informasi selengkapnya, lihat Membangun template.
Untuk memulai pipeline streaming replikasi terbalik, jalankan perintah gcloud dataflow flex-template run berikut:
```
  gcloud dataflow flex-template run "spanner-to-sourcedb-job" \
  --project "PROJECT" \
  --region "REGION" \
  --template-file-gcs-location "TEMPLATE_SPEC_GCSPATH" \
  --parameters "changeStreamName=CHANGE_STREAM_NAME" \
  --parameters "instanceId=INSTANCE_ID" \
  --parameters "databaseId=DATABASE_ID" \
  --parameters "spannerProjectId=SPANNER_PROJECT_ID" \
  --parameters "metadataInstance=METADATA_INSTANCE" \
  --parameters "metadataDatabase=METADATA_DATABASE" \
  --parameters "sourceShardsFilePath=SOURCE_SHARDS_FILE_PATH" \
  # All flags after this point are optional
  [--parameters "startTimestamp=START_TIMESTAMP"] \
  [--parameters "endTimestamp=END_TIMESTAMP"] \
  [--parameters "shadowTablePrefix=SHADOW_TABLE_PREFIX"] \
  [--parameters "sessionFilePath=SESSION_FILE_PATH"] \
  [--parameters "filtrationMode=FILTRATION_MODE"] \
  [--parameters "shardingCustomJarPath=SHARDING_CUSTOM_JAR_PATH"] \
  [--parameters "shardingCustomClassName=SHARDING_CUSTOM_CLASS_NAME"] \
  [--parameters "shardingCustomParameters=SHARDING_CUSTOM_PARAMETERS"] \
  [--parameters "sourceDbTimezoneOffset=SOURCE_DB_TIMEZONE_OFFSET"] \
  [--parameters "dlqGcsPubSubSubscription=DLQ_GCS_PUB_SUB_SUBSCRIPTION"] \
  [--parameters "skipDirectoryName=SKIP_DIRECTORY_NAME"] \
  [--parameters "maxShardConnections=MAX_SHARD_CONNECTIONS"] \
  [--parameters "deadLetterQueueDirectory=DEAD_LETTER_QUEUE_DIRECTORY"] \
  [--parameters "dlqMaxRetryCount=DLQ_MAX_RETRY_COUNT"] \
  [--parameters "runMode=RUN_MODE"] \
  [--parameters "dlqRetryMinutes=DLQ_RETRY_MINUTES"] \
  [--parameters "sourceType=SOURCE_TYPE"] \
  [--parameters "transformationJarPath=TRANSFORMATION_JAR_PATH"] \
  [--parameters "transformationClassName=TRANSFORMATION_CLASS_NAME"] \
  [--parameters "transformationCustomParameters=TRANSFORMATION_CUSTOM_PARAMETERS"] \
  [--parameters "filterEventsDirectoryName=FILTER_EVENTS_DIRECTORY_NAME"]
```
Variabel wajib dijelaskan dalam daftar berikut:
- PROJECT: Google Cloud Project ID
- REGION: Google Cloud region tempat Anda ingin menjalankan tugas Dataflow.
- TEMPLATE_SPEC_GCSPATH: jalur Cloud Storage ke file template Dataflow yang disiapkan.
- CHANGE_STREAM_NAME: nama aliran perubahan Spanner yang dibaca tugas.
- INSTANCE_ID: ID instance Spanner.
- DATABASE_ID: ID database Spanner.
- SPANNER_PROJECT_ID: Project ID tempat instance Spanner Anda berada.
- METADATA_INSTANCE: instance Spanner yang menyimpan metadata yang digunakan konektor untuk mengontrol penggunaan data API aliran perubahan.
- METADATA_DATABASE: database Spanner yang menyimpan metadata yang digunakan konektor untuk mengontrol penggunaan data API aliran perubahan.
- SOURCE_SHARDS_FILE_PATH: jalur Cloud Storage yang berisi informasi profil koneksi untuk shard sumber.
Variabel opsional dijelaskan dalam daftar berikut:
- START_TIMESTAMP: stempel waktu untuk mulai membaca perubahan. Nilai defaultnya adalah kosong.
- END_TIMESTAMP: stempel waktu hingga perubahan dibaca. Jika tidak ditentukan, proses akan membaca perubahan tanpa batas. Nilai defaultnya adalah kosong.
- SHADOW_TABLE_PREFIX: awalan untuk memberi nama tabel bayangan. Default: shadow_.
- SESSION_FILE_PATH: jalur ke file sesi di Cloud Storage yang berisi informasi pemetaan dari alat migrasi Spanner.
- FILTRATION_MODE: mode yang menentukan cara memfilter data berdasarkan kriteria. Mode yang didukung adalah none dan forward_migration.
- SHARDING_CUSTOM_JAR_PATH: lokasi (jalur) di Cloud Storage dari file JAR kustom yang berisi logika untuk mengambil ID shard. Nilai defaultnya adalah kosong.
- SHARDING_CUSTOM_CLASS_NAME: nama class yang sepenuhnya memenuhi syarat yang memiliki implementasi ID shard kustom. Parameter ini diperlukan jika SHARDING_CUSTOM_JAR_PATH ditentukan. Nilai defaultnya adalah kosong.
- SHARDING_CUSTOM_PARAMETERS: string yang berisi parameter kustom apa pun yang akan diteruskan ke class sharding kustom. Nilai defaultnya adalah kosong.
- SOURCE_DB_TIMEZONE_OFFSET: offset zona waktu dari UTC untuk database sumber. Misalnya, +10:00. Default: +00:00.
- DLQ_GCS_PUB_SUB_SUBSCRIPTION: langganan Pub/Sub yang digunakan dalam kebijakan notifikasi Cloud Storage untuk direktori percobaan ulang DLQ saat berjalan dalam mode regular. Tentukan nama dalam format projects/<PROJECT_ID>/subscriptions/<SUBSCRIPTION_ID>. Saat Anda menetapkan parameter ini, sistem akan mengabaikan deadLetterQueueDirectory dan dlqRetryMinutes.
- SKIP_DIRECTORY_NAME: direktori tempat sistem menulis data yang dilewati selama replikasi terbalik. Default: skip.
- MAX_SHARD_CONNECTIONS: jumlah maksimum koneksi yang diizinkan per shard. Default: 10000.
- DEAD_LETTER_QUEUE_DIRECTORY: jalur untuk menyimpan output DLQ. Defaultnya adalah direktori di lokasi sementara tugas Dataflow.
- DLQ_MAX_RETRY_COUNT: jumlah maksimum percobaan ulang error sementara oleh sistem melalui DLQ. Default: 500.
- RUN_MODE: jenis mode run. Opsi yang didukung adalah regular, retryDLQ, dan retryAllDLQ. Gunakan retryDLQ untuk mencoba ulang data error dari direktori severe/ bersama dengan pipeline aktif, atau retryAllDLQ untuk memproses direktori retry/ dan severe/ saat pipeline reguler dihentikan. Default: regular.
- DLQ_RETRY_MINUTES: jumlah menit antara percobaan ulang DLQ. Default: 10.
- SOURCE_TYPE: jenis database sumber untuk melakukan replikasi terbalik. Default: mysql.
- TRANSFORMATION_JAR_PATH: lokasi (jalur) di Cloud Storage dari file JAR kustom yang berisi logika transformasi kustom untuk memproses data dalam replikasi terbalik. Nilai defaultnya adalah kosong.
- TRANSFORMATION_CLASS_NAME: nama class yang sepenuhnya memenuhi syarat yang memiliki logika transformasi kustom. Parameter ini diperlukan jika TRANSFORMATION_JAR_PATH ditentukan. Nilai defaultnya adalah kosong.
- TRANSFORMATION_CUSTOM_PARAMETERS: string yang berisi parameter kustom apa pun yang akan diteruskan ke class transformasi kustom. Nilai defaultnya adalah kosong.
- FILTER_EVENTS_DIRECTORY_NAME: direktori di Cloud Storage tempat sistem menulis data yang difilter oleh logika transformasi terbalik kustom. Default: filteredEvents.

Memantau dan mengatasi error replikasi terbalik

Saat menjalankan replikasi terbalik dari Spanner kembali ke MySQL, jika tugas Dataflow streaming Anda tidak dapat menulis peristiwa perubahan ke database utama MySQL, tugas tersebut akan mengklasifikasikan kegagalan ke dalam salah satu dari dua kategori dan menulis data ke direktori antrean pesan yang tidak terkirim di bucket Cloud Storage Anda:

Error yang dapat dicoba ulang: Kegagalan sementara, seperti pertentangan kunci database MySQL atau waktu tunggu koneksi jaringan. Dataflow menulis peristiwa ini ke direktori antrean pesan yang tidak terkirim retry/ dan otomatis mencoba ulang dalam pipeline yang sama hingga berhasil atau melebihi dlqMaxRetryCount.
Error parah: Kegagalan permanen yang tidak dapat diselesaikan dengan percobaan ulang otomatis, seperti error konversi jenis data, error sintaksis, atau pengecualian di dalam JAR transformasi kustom. Dataflow menulis peristiwa ini ke direktori antrean pesan yang tidak terkirim severe/ (misalnya, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/) dan meningkatkan penghitung pengguna kustom severe_error_count.

Karena error parah tidak dapat diselesaikan dengan percobaan ulang otomatis, Dataflow akan menghapus peristiwa yang gagal tersebut dari aliran replikasi aktif dan menyimpannya di direktori severe/. Jika tidak ditangani, database MySQL rollback Anda akan kehilangan data tersebut. Pantau penghitung severe_error_count dan direktori severe/ secara rutin selama replikasi terbalik sehingga Anda dapat mengatasi dan memutar ulang peristiwa perubahan yang gagal sebelum memulai rollback.

Penghitung kustom Dataflow severe_error_count adalah metrik kumulatif yang mencatat jumlah total error parah yang terjadi sejak tugas streaming dimulai. Saat Anda memutar ulang dan mengatasi data yang gagal menggunakan tugas percobaan ulang DLQ, penghitung ini di pipeline streaming asli Anda tidak akan berkurang. Oleh karena itu, direktori DLQ parah Cloud Storage Anda (gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/) adalah sumber kebenaran yang otoritatif untuk mengetahui apakah ada error yang tidak tertangani.

Memutar ulang data yang gagal

Saat data yang gagal muncul di direktori DLQ parah, periksa file error JSON di Cloud Storage, identifikasi penyebab utamanya, dan atasi masalah yang mendasarinya.

Untuk memutar ulang data DLQ yang telah diperbaiki ke MySQL, luncurkan tugas Dataflow baru menggunakan salah satu mode run berikut:

Mode retryDLQ: Jalankan mode ini sebagai tugas batch bersama dengan pipeline streaming aktif Anda untuk memproses file error di direktori severe/ tanpa menghentikan replikasi terbalik langsung. Jalankan mode ini setelah mengatasi penyebab utama error parah Anda.
Mode retryAllDLQ: Jika pipeline streaming reguler Anda dihentikan, gunakan mode ini untuk memproses direktori retry/ dan severe/. Jangan menjalankan retryAllDLQ secara bersamaan dengan pipeline aktif, karena akan menyebabkan pertentangan file dan konflik pemrosesan.

Untuk meluncurkan tugas percobaan ulang DLQ replikasi terbalik menggunakan gcloud CLI CLI, jalankan perintah berikut:

gcloud dataflow flex-template run "spanner-to-sourcedb-retry-job" \
    --project "PROJECT" \
    --region "REGION" \
    --template-file-gcs-location "TEMPLATE_SPEC_GCSPATH" \
    --parameters "changeStreamName=CHANGE_STREAM_NAME" \
    --parameters "instanceId=INSTANCE_ID" \
    --parameters "databaseId=DATABASE_ID" \
    --parameters "spannerProjectId=SPANNER_PROJECT_ID" \
    --parameters "metadataInstance=METADATA_INSTANCE" \
    --parameters "metadataDatabase=METADATA_DATABASE" \
    --parameters "sourceShardsFilePath=SOURCE_SHARDS_FILE_PATH" \
    --parameters "deadLetterQueueDirectory=DLQ_DIRECTORY" \
    --parameters "runMode=retryDLQ"

Ganti kode berikut:

PROJECT: Google Cloud Project ID
REGION: Google Cloud region tempat Anda ingin menjalankan tugas Dataflow.
TEMPLATE_SPEC_GCSPATH: jalur Cloud Storage ke file template Dataflow yang disiapkan.
CHANGE_STREAM_NAME: nama aliran perubahan Spanner yang dibaca tugas.
INSTANCE_ID: ID instance Spanner.
DATABASE_ID: ID database Spanner.
SPANNER_PROJECT_ID: Project ID tempat instance Spanner Anda berada.
METADATA_INSTANCE: instance Spanner yang menyimpan metadata yang digunakan konektor untuk mengontrol penggunaan data API aliran perubahan.
METADATA_DATABASE: database Spanner yang menyimpan metadata yang digunakan konektor untuk mengontrol penggunaan data API aliran perubahan.
SOURCE_SHARDS_FILE_PATH: jalur Cloud Storage yang berisi informasi profil koneksi untuk shard sumber.
DLQ_DIRECTORY: jalur Cloud Storage ke direktori antrean pesan yang tidak terkirim yang berisi file error parah untuk dicoba ulang.