Migrasi Data MySQL ke Azure Database for MySQL - Rekam Jepret Konsisten MySQL

2024-09-18

MySQL Consistent Snapshot adalah fitur baru yang memungkinkan pengguna untuk mengambil Rekam Jepret Konsisten server MySQL tanpa kehilangan integritas data di sumber karena operasi CRUD (Buat, Baca, Perbarui, dan Hapus) yang sedang berlangsung. Konsistensi transaksional dicapai tanpa perlu mengatur server sumber ke mode baca-saja melalui fitur ini. Selain itu, ada beberapa opsi konsistensi data yang disajikan kepada pengguna - aktifkan rekam jepret yang konsisten dengan kunci baca (GA), aktifkan rekam jepret yang konsisten tanpa kunci (Pratinjau), Buat Server Sumber Baca saja dan Tidak Ada. Memilih opsi 'Tidak Ada' tidak memerlukan tindakan tambahan yang diambil untuk memastikan konsistensi data. Kedua opsi - aktifkan rekam jepret yang konsisten dengan kunci baca (GA), aktifkan rekam jepret yang konsisten tanpa dukungan penguncian yang melakukan migrasi online. Sebaiknya pilih opsi 'Aktifkan Rekam Jepret Konsisten tanpa kunci' untuk mempertahankan konsistensi transaksional.

Aktifkan Rekam Jepret Konsisten tanpa kunci (GA)

Saat Anda mengaktifkan opsi ini, fase rekonsiliasi akan terjadi setelah beban awal. Ini untuk memastikan bahwa data yang ditulis ke target Anda konsisten secara transaksional dengan server sumber dari posisi tertentu di log biner.

Dengan fitur ini, kami tidak mengambil kunci baca di server. Sebagai gantinya, kita membaca tabel pada titik waktu yang berbeda, sambil melacak posisi binlog yang berbeda dari setiap tabel. Ini membantu mendamaikan tabel menjelang akhir beban awal dengan melakukan replikasi dalam mode catchup untuk mendapatkan rekam jepret yang konsisten.

Fitur utama Rekam Jepret Konsisten tanpa kunci:

Kemampuan untuk mendukung server atau server beban kerja berat dengan transaksi yang berjalan lama tanpa perlu kunci baca.
Tangguh dalam menyelesaikan migrasi bahkan jika terjadi kegagalan yang disebabkan oleh blip jaringan/server sementara yang mengakibatkan hilangnya semua koneksi yang telah dibuat sebelumnya.

Aktifkan Rekam Jepret Konsisten dengan kunci baca (GA)

Saat Anda mengaktifkan opsi ini, layanan menghapus semua tabel di server sumber dengan kunci baca untuk mendapatkan rekam jepret titik waktu. Pembilasan ini dilakukan karena kunci global lebih dapat diandalkan daripada mencoba mengunci database atau tabel individual. Akibatnya, bahkan jika Anda tidak memigrasikan semua database di server, database tersebut dikunci sebagai bagian dari menyiapkan proses migrasi. Layanan migrasi memulai bacaan berulang dan menggabungkan status tabel saat ini dengan konten log urungkan untuk rekam jepret. Rekam jepret dihasilkan setelah mendapatkan kunci lebar server selama beberapa detik dan menelurkan beberapa koneksi untuk migrasi. Setelah pembuatan semua koneksi yang digunakan untuk migrasi, kunci pada tabel dirilis.

Pembacaan yang dapat diulang diaktifkan untuk menjaga log batalkan dapat diakses selama migrasi, yang meningkatkan penyimpanan yang diperlukan pada sumber karena koneksi yang berjalan lama. Migrasi yang berjalan lama dengan beberapa perubahan tabel menyebabkan riwayat log urungkan yang luas yang perlu diputar ulang dan juga dapat meningkatkan persyaratan komputasi dan beban di server sumber.

Buat server sumber baca saja

Memilih opsi ini mempertahankan integritas data database target saat sumber dimigrasikan dengan mencegah operasi Tulis/Hapus di server sumber selama migrasi. Saat Anda membuat server sumber hanya membaca sebagai bagian dari proses migrasi, pilihan berlaku untuk semua database server sumber, terlepas dari apakah server tersebut dipilih untuk migrasi.

Membuat server sumber baca hanya mencegah pengguna mengubah data, merender database tidak tersedia untuk operasi pembaruan apa pun. Namun, jika opsi ini tidak diaktifkan, ada kemungkinan pembaruan data terjadi selama migrasi. Akibatnya, data yang dimigrasikan bisa tidak konsisten karena rekam jepret database akan dibaca pada titik waktu yang berbeda.

Prasyarat untuk Mengaktifkan Rekam Jepret Konsisten dengan kunci baca

Agar migrasi berhasil diselesaikan dengan Rekam Jepret Konsisten dengan kunci baca diaktifkan:

Pastikan bahwa pengguna yang mencoba menghapus tabel dengan kunci baca memiliki izin MUAT ULANG atau FLUSH.
Gunakan alat klien mysql untuk menentukan apakah log_bin diaktifkan di server sumber. Log Bin tidak selalu diaktifkan secara default dan harus diperiksa untuk melihat apakah log tersebut diaktifkan sebelum memulai migrasi. Alat klien mysql digunakan untuk menentukan apakah log_bin diaktifkan pada sumber dengan menjalankan perintah: TAMPILKAN VARIABEL SEPERTI 'log_bin';

Catatan

Dengan Server Tunggal Azure Database for MySQL, yang mendukung hingga 4TB, ini tidak diaktifkan secara default. Namun, jika Anda mempromosikan replika baca untuk server sumber lalu menghapus replika baca, parameter diatur ke AKTIF.

Konfigurasikan parameter binlog_expire_logs_seconds di server sumber untuk memastikan bahwa file binlog tidak dihapus menyeluruh sebelum replika menerapkan perubahan. Pasca cutover berhasil, nilai dapat diatur ulang.

Masalah dan batasan yang diketahui untuk Mengaktifkan Rekam Jepret Konsisten tanpa kunci

Tabel dengan kunci asing yang memiliki Cascade atau Atur Null pada klausa hapus/saat pembaruan tidak didukung.
Tidak ada perubahan DDL yang harus terjadi selama pemuatan awal.

Masalah dan batasan yang diketahui untuk Mengaktifkan Rekam Jepret Konsisten dengan kunci baca

Masalah dan batasan yang diketahui yang terkait dengan Pencadangan Konsisten secara luas termasuk dalam dua kategori: kunci dan percobaan ulang.

Catatan

Layanan migrasi menjalankan kueri START TRANSACTION WITH CONSISTENT SNAPSHOT untuk semua utas pekerja untuk mendapatkan rekam jepret server. Tetapi ini hanya didukung oleh InnoDB. Info selengkapnya di sini.

Penguncian

Biasanya, ini adalah proses mudah untuk mendapatkan kunci, yang harus memakan waktu antara beberapa detik dan beberapa menit untuk diselesaikan. Namun, dalam beberapa skenario, upaya untuk mendapatkan kunci pada server sumber dapat gagal.

Kehadiran kueri yang berjalan lama dapat mengakibatkan waktu henti yang tidak perlu, karena DMS dapat mengunci subset tabel dan kemudian waktu habis menunggu beberapa terakhir tersedia. Sebelum memulai migrasi, periksa operasi yang berjalan lama dengan menjalankan perintah SHOW PROCESSLIST .
Jika server sumber mengalami banyak pembaruan tulis pada saat kunci diminta, kunci tidak dapat dengan mudah diperoleh dan dapat gagal setelah batas waktu tunggu penguncian. Ini terjadi dalam kasus tugas pemrosesan batch dalam tabel, yang ketika sedang berlangsung dapat mengakibatkan menolak permintaan kunci. Seperti disebutkan sebelumnya, kunci yang diminta adalah kunci tingkat global tunggal untuk seluruh server sehingga bahkan jika satu tabel atau database sedang diproses, permintaan kunci harus menunggu tugas yang sedang berlangsung untuk menyimpulkan.
Batasan lain berkaitan dengan migrasi dari server sumber AWS RDS. RDS tidak mendukung tabel flush dengan kunci baca dan kueri LOCK TABLE dijalankan pada tabel yang dipilih di bawah kap. Karena tabel dikunci satu per satu, proses penguncian bisa kurang dapat diandalkan, dan kunci dapat memakan waktu lebih lama untuk diperoleh.

Percobaan kembali

Migrasi menangani masalah koneksi sementara dan koneksi tambahan biasanya disediakan di muka untuk tujuan ini. Kami melihat pengaturan migrasi, terutama jumlah operasi baca paralel pada sumber dan menerapkan faktor (biasanya ~ 1,5) dan membuat koneksi sebanyak mungkin di muka. Dengan cara ini layanan memastikan kami dapat menjaga operasi tetap berjalan secara paralel. Pada titik waktu mana pun, jika ada kehilangan koneksi atau layanan tidak dapat memperoleh kunci, layanan menggunakan koneksi surplus yang disediakan untuk mencoba kembali migrasi. Jika semua koneksi yang disediakan habis mengakibatkan hilangnya sinkronisasi titik waktu, migrasi harus dimulai ulang dari awal. Dalam kasus keberhasilan dan kegagalan, semua tindakan pembersihan dilakukan oleh layanan migrasi offline ini dan pengguna tidak perlu melakukan tindakan pembersihan eksplisit.

Bagikan melalui