Mengonfigurasi penggantian untuk MySQL

Halaman ini menjelaskan cara menyiapkan 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 ke database MySQL sumber. Hal ini memastikan kedua database pada akhirnya konsisten.

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

  1. Membaca perubahan dari Spanner menggunakan aliran perubahan Spanner.

  2. Memastikan mode pemfilteran adalah forward_migration.

  3. Mengubah data Spanner agar kompatibel dengan skema database sumber menggunakan alat migrasi Spanner. Untuk mengetahui informasi selengkapnya, lihat Transformasi kustom.

  4. Memverifikasi apakah database sumber sudah berisi data yang lebih baru untuk kunci utama yang ditentukan.

  5. Menulis data ke database sumber.

Menggunakan template Dataflow Spanner_to_SourceDb

Template Dataflow 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.

Anda dapat mengonfigurasi tugas Dataflow yang melakukan replikasi terbalik untuk berjalan dalam salah satu mode berikut:

  • Reguler: Ini adalah mode default. Tugas Dataflow membaca peristiwa dari aliran perubahan Spanner, mengonversinya ke jenis data yang kompatibel dengan skema database sumber, dan menerapkannya ke database sumber. Tugas ini otomatis mencoba kembali error. Setelah mencoba kembali, tugas ini akan memindahkan error ke folder severe dari direktori antrean surat mati (DLQ) di bucket Cloud Storage. Tugas ini juga memindahkan semua error permanen ke folder severe.

  • RetryDLQ: Dalam mode ini, tugas Dataflow membaca peristiwa dari folder severe DLQ dan mencoba kembali. Jalankan mode ini setelah Anda memperbaiki semua error permanen. Mode ini hanya membaca dari DLQ, dan bukan dari aliran perubahan Spanner. Jika data yang diproses dari folder severe dipindahkan ke folder retry, tugas akan mencoba kembali.

Sebelum memulai

  • Pastikan konektivitas jaringan antara database MySQL sumber dan Google Cloud project Anda, tempat tugas Dataflow akan berjalan.

  • Izinkan alamat IP pekerja Dataflow di instance MySQL tujuan Anda.

  • 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 Membuat dan menjalankan template fleksibel.

  • Pastikan port 12345 terbuka untuk komunikasi antara VM pekerja Dataflow.

Peran yang diperlukan

  • Untuk mendapatkan izin yang Anda perlukan untuk meluncurkan replikasi terbalik, minta administrator untuk memberi Anda peran IAM berikut pada instance:

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

Menjalankan replikasi terbalik

Untuk menjalankan replikasi terbalik, ikuti langkah-langkah berikut:

  1. Upload file sesi ke bucket Cloud Storage.

  2. Buat notifikasi Pub/Sub untuk folder retry dari direktori DLQ. Anda dapat melakukannya dengan membuat topik Pub/Sub dan langganan Pub/Sub untuk topik tersebut.

  3. Buat dan siapkan template Dataflow. Untuk mengetahui informasi selengkapnya, lihat Membuat template.

  4. Jalankan template Dataflow replikasi terbalik menggunakan perintah Google Cloud CLI 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" \
  --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: Project ID Google Cloud
    • region: Region Google Cloud
    • template-file-gcs-location: jalur ke file Cloud Storage tempat Anda menyiapkan template Dataflow.
    • changeStreamName: nama aliran perubahan Spanner yang dibaca oleh tugas.
    • instanceId: ID instance Spanner.
    • databaseId: ID database Spanner.
    • spannerProjectId: project ID tempat instance Spanner Anda berada.
    • metadataInstance: instance yang menyimpan metadata yang digunakan konektor untuk mengontrol penggunaan data API aliran perubahan.
    • metadataDatabase: database yang menyimpan metadata yang digunakan konektor untuk mengontrol penggunaan data API aliran perubahan.
    • sourceShardsFilePath: jalur ke file Cloud Storage yang berisi informasi profil koneksi untuk shard sumber.

    Variabel opsional dijelaskan dalam daftar berikut:

    • startTimestamp: stempel waktu untuk mulai membaca perubahan. Nilai defaultnya adalah kosong.
    • endTimestamp: stempel waktu untuk membaca perubahan. Jika Anda tidak memberikan stempel waktu, proses akan membaca perubahan tanpa batas waktu. Nilai defaultnya adalah kosong.
    • shadowTablePrefix: awalan untuk memberi nama tabel bayangan. Nilai defaultnya adalah shadow_.
    • sessionFilePath: jalur ke file sesi di Cloud Storage yang berisi informasi pemetaan dari alat migrasi Spanner.
    • filtrationMode: mode yang menentukan cara memfilter data berdasarkan kriteria. Mode yang didukung adalah none atau forward_migration.
    • shardingCustomJarPath: lokasi (jalur) di Cloud Storage dari file JAR kustom yang berisi logika untuk mengambil ID shard. Nilai defaultnya adalah kosong.
    • shardingCustomClassName: nama class yang sepenuhnya memenuhi syarat yang memiliki implementasi ID shard kustom. Kolom ini wajib diisi jika shardingCustomJarPath ditentukan. Nilai defaultnya adalah kosong.
    • shardingCustomParameters: string yang berisi parameter kustom untuk diteruskan ke class sharding kustom. Nilai defaultnya adalah kosong.
    • sourceDbTimezoneOffset: offset zona waktu dari UTC untuk database sumber. Contoh: +10:00. Default: +00:00.
    • dlqGcsPubSubSubscription: 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.
    • skipDirectoryName: direktori tempat sistem menulis data yang dilewati selama replikasi terbalik. Default: skip.
    • maxShardConnections: jumlah maksimum koneksi yang diizinkan per shard. Default: 10000.
    • deadLetterQueueDirectory: jalur untuk menyimpan output DLQ. Defaultnya adalah direktori di lokasi sementara tugas Dataflow.
    • dlqMaxRetryCount: jumlah maksimum percobaan ulang error sementara oleh sistem melalui DLQ. Default: 500.
    • runMode: jenis mode run. Opsinya adalah regular atau retryDLQ. Gunakan retryDLQ untuk mencoba kembali hanya data DLQ yang parah. Default: regular.
    • dlqRetryMinutes: jumlah menit antara percobaan ulang DLQ. Default: 10.
    • sourceType: jenis database sumber untuk melakukan replikasi terbalik. Default: mysql.
    • transformationJarPath: lokasi (jalur) di Cloud Storage dari file JAR kustom yang berisi logika transformasi kustom untuk memproses data dalam replikasi terbalik. Nilai defaultnya adalah kosong.
    • transformationClassName: nama class yang sepenuhnya memenuhi syarat yang memiliki logika transformasi kustom. Kolom ini wajib diisi jika transformationJarPath ditentukan. Nilai defaultnya adalah kosong.
    • transformationCustomParameters: string yang berisi parameter kustom untuk diteruskan ke class transformasi kustom. Nilai defaultnya adalah kosong.
    • filterEventsDirectoryName: direktori tempat sistem menulis data yang dilewati selama replikasi terbalik. Default: skip.

Langkah berikutnya