Mengonfigurasi penggantian untuk MySQL

Halaman ini menjelaskan cara menyiapkan penggantian untuk MySQL menggunakan replikasi terbalik. Penggantian mengacu pada rencana darurat 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 fallback ke database MySQL asli dengan gangguan minimum pada layanan. Replikasi terbalik memungkinkan Anda melakukan failback dengan mereplikasi data yang ditulis ke Spanner ke database MySQL sumber Anda. Hal ini memastikan kedua database pada akhirnya konsisten.

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

  1. Membaca perubahan dari Spanner menggunakan aliran perubahan Spanner.

  2. Pastikan mode pemfilteran adalah forward_migration.

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

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

  5. Tulis data ke database sumber Anda.

Menggunakan template Dataflow Spanner_to_SourceDb

Template Dataflow memastikan konsistensi di tingkat kunci utama. Template 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 penerapan kunci utama.

Anda dapat mengonfigurasi tugas Dataflow yang melakukan replikasi terbalik agar 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 akan otomatis mencoba lagi jika terjadi error. Setelah mencoba ulang beberapa kali, error akan dipindahkan ke folder severe di direktori dead letter queue (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 ulang peristiwa tersebut. Jalankan mode ini setelah Anda memperbaiki semua error permanen. Mode ini hanya membaca dari DLQ, dan bukan dari aliran perubahan Spanner. Jika kumpulan data yang diproses dari folder severe dipindahkan ke folder retry, tugas akan mencoba lagi.

Sebelum memulai

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

  • Masukkan alamat IP pekerja Dataflow ke daftar yang diizinkan di instance MySQL tujuan Anda.

  • Pastikan kredensial MySQL ditentukan dengan benar di source shards file.

  • Pastikan instance MySQL Anda online dan berjalan.

  • Pastikan pengguna MySQL memiliki hak istimewa INSERT, UPDATE, dan DELETE pada 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 pekerja Dataflow.

Peran yang diperlukan

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

  • Untuk memastikan bahwa akun layanan Compute Engine memiliki izin yang diperlukan untuk meluncurkan replikasi terbalik, minta administrator untuk memberikan peran IAM berikut kepada akun layanan Compute Engine di 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. Bangun dan siapkan template Dataflow. Untuk mengetahui informasi selengkapnya, lihat Membangun 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: Google Cloud Project ID
    • region: Google Cloud region.
    • template-file-gcs-location: jalur ke file Cloud Storage tempat Anda menyiapkan template Dataflow.
    • changeStreamName: nama aliran perubahan Spanner yang dibaca 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 Change Stream API.
    • metadataDatabase: database yang menyimpan metadata yang digunakan konektor untuk mengontrol penggunaan data Change Stream API.
    • sourceShardsFilePath: jalur ke file Cloud Storage yang berisi informasi profil koneksi untuk shard sumber.

    Variabel opsional dijelaskan dalam daftar berikut:

    • startTimestamp: stempel waktu dari mana perubahan mulai dibaca. Nilai defaultnya adalah kosong.
    • endTimestamp: stempel waktu hingga perubahan dibaca. 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 rekaman 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 memenuhi syarat sepenuhnya yang memiliki implementasi ID partisi kustom. Kolom ini wajib diisi jika shardingCustomJarPath ditentukan. Nilai defaultnya adalah kosong.
    • shardingCustomParameters: string yang berisi parameter kustom apa pun yang akan diteruskan ke class sharding kustom. Nilai defaultnya adalah kosong.
    • sourceDbTimezoneOffset: selisih 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 catatan 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 sistem untuk mengatasi kesalahan sementara melalui DLQ. Default: 500.
    • runMode: jenis mode operasi. Opsinya adalah regular atau retryDLQ. Gunakan retryDLQ untuk mencoba ulang hanya rekaman DLQ yang parah. Default: regular.
    • dlqRetryMinutes: jumlah menit antara percobaan ulang DLQ. Default: 10.
    • sourceType: jenis database sumber yang akan direplikasi terbalik. Default: mysql.
    • transformationJarPath: lokasi (jalur) di Cloud Storage dari file JAR kustom yang berisi logika transformasi kustom untuk memproses rekaman 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 catatan yang dilewati selama replikasi terbalik. Default: skip.

Apa langkah selanjutnya?