ApsaraDB RDS:\[Tidak Direkomendasikan\]\ Konversi\ TokuDB\ ke\ InnoDB

Latar Belakang

Percona telah menghentikan pemeliharaan TokuDB, sehingga bug yang diketahui tidak diperbaiki dan dalam kasus ekstrem dapat menyebabkan kerugian bisnis. Akibatnya, ApsaraDB RDS for MySQL mencabut dukungan terhadap TokuDB pada 1 Agustus 2019.

• Tanggal berlaku: 1 Agustus 2019

• Cakupan yang terdampak: Instans RDS yang menggunakan mesin penyimpanan TokuDB

Periksa apakah instans Anda terdampak

Jalankan pernyataan SQL berikut di Data Management (DMS) untuk mengidentifikasi tabel TokuDB:

-- Lihat mesin penyimpanan default instans RDS Anda
SHOW ENGINES;

-- Lihat mesin penyimpanan tabel tertentu
SHOW CREATE TABLE <table_name>;

Dampak potensial

Sebelum melakukan migrasi, tinjau dampak berikut:

• CPU dan IOPS: Setelah migrasi, penggunaan CPU menurun tetapi IOPS meningkat saat membaca volume data yang sama, karena InnoDB tidak mengompresi halaman data.

• Perubahan titik akhir: Migrasi penuh akan mengganti titik akhir koneksi. Jadwalkan migrasi selama jam sepi.

• Perubahan versi mesin: Jika Anda mengubah versi mesin database selama migrasi, uji kompatibilitas terlebih dahulu.

Pilih solusi

Pilih solusi berdasarkan ukuran tabel dan toleransi terhadap downtime:

Setelah menyelesaikan solusi apa pun, ubah nilai parameter default_storage_engine menjadi InnoDB. Jika langkah ini dilewati, tabel baru yang dibuat tanpa klausa eksplisit ENGINE akan tetap mencoba menggunakan TokuDB — yang tidak lagi didukung dan menyebabkan error. Lihat Setelah migrasi.

Solusi 1: ALTER TABLE (langsung)

Solusi ini secara langsung mengubah mesin penyimpanan dengan satu pernyataan SQL. Operasi DML diblokir selama proses berlangsung, sehingga hanya cocok untuk tabel kecil yang dapat menerima blocking singkat.

1. Login ke instans RDS Anda menggunakan .

2. Pada bilah navigasi atas, pilih SQL Operations > SQL Window.

3. Jalankan pernyataan berikut:

   ALTER TABLE test.testfs ENGINE = InnoDB;

   

Solusi 2: gh-ost (migrasi online)

Solusi ini menggunakan gh-ost, tool open-source online DDL yang dikembangkan oleh GitHub. Tool ini menyalin data ke tabel ghost di latar belakang dan melakukan cutover selama jam sepi, sehingga operasi DML tetap tidak terblokir.

Cara kerja

gh-ost membuat tabel ghost sementara dengan skema yang sama seperti aslinya, menyalin data secara inkremental, lalu membaca log biner melalui replika simulasi untuk memainkan ulang perubahan yang sedang berlangsung. Saat Anda siap, gh-ost mengganti nama tabel untuk menyelesaikan cutover. Terjadi lonjakan I/O selama penyalinan penuh awal, tetapi parameter --chunk-size memungkinkan Anda membatasi throughput.

• Keuntungan: Memungkinkan Anda menentukan waktu cutover secara tepat serta menjeda atau membatalkan kapan saja.

• Batasan: Setiap tabel memerlukan perintah terpisah, yang menjadi merepotkan jika jumlah tabel sangat banyak. Gunakan Solusi 3 sebagai gantinya.

Solusi 3: Sinkronisasi tingkat tabel DTS

Solusi ini menggunakan Data Transmission Service (DTS) untuk menyinkronkan data dari tabel TokuDB asli ke tabel InnoDB baru secara real-time, lalu mengganti nama tabel selama jam sepi. Solusi ini dapat menangani banyak tabel secara bersamaan, sehingga cocok untuk migrasi massal.

Instansi sinkronisasi data DTS dikenai biaya terpisah. Untuk detail harga, lihat Harga Data Transmission Service.

1. Login ke instans RDS Anda menggunakan .

2. Pada bilah navigasi atas, pilih SQL Operations > SQL Window.

3. Buat tabel InnoDB sementara dengan skema yang sama seperti tabel TokuDB Anda. Contohnya:

   CREATE TABLE `testfs_tmp` (
     `id` int(11) NOT NULL AUTO_INCREMENT,
     `vc` varchar(8000) DEFAULT NULL,
     PRIMARY KEY (`id`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

4. Beli instans DTS.

5. Pada panel navigasi kiri Konsol DTS, klik Data Synchronization.

6. Temukan instans yang telah dibeli dan klik Configure Synchronization Channel di kolom Actions.

7. Konfigurasikan detail instans sumber dan tujuan:

   Enkripsi SSL secara signifikan meningkatkan penggunaan CPU. Untuk instruksi pengaturan, lihat Konfigurasi Enkripsi SSL untuk instans RDS.

   Bagian	Parameter	Nilai
   Detail instans sumber	Jenis instans	RDS Instance
   	ID Instans	Pilih instans RDS yang akan dimigrasi
   	Enkripsi	Non-encrypted atau SSL-encrypted
   Detail instans tujuan	Jenis instans	RDS Instance
   	Instance ID	Pilih instans RDS yang sama
   	Enkripsi	Non-encrypted atau SSL-encrypted

   

8. Klik Set Whitelist and Next.

9. Tunggu hingga akun sinkronisasi dibuat, lalu klik Next.

10. Pindahkan tabel testfs ke bagian tabel terpilih dan klik Edit.

    

11. Atur nama tabel tujuan menjadi testfs_tmp dan klik OK.

    

12. Klik Next.

13. Pilih Initial Full Data Synchronization dan klik Precheck.

    

14. Tunggu hingga pemeriksaan awal selesai, lalu klik Close.

15. Tunggu hingga nilai Delay turun menjadi 0 Milliseconds, yang berarti kedua tabel telah sepenuhnya tersinkronisasi.

    

16. Di SQL Window DMS, ganti nama tabel untuk menyelesaikan cutover:

    DTS melaporkan error sinkronisasi setelah penggantian nama — hal ini diharapkan dan dapat diabaikan.

     RENAME TABLE `testfs` TO `testfs_del`, `testfs_tmp` TO `testfs`;

17. Verifikasi data. Setelah dipastikan benar, rilis instans DTS untuk menghentikan penagihan dan hapus tabel testfs_del.

Solusi 4: Migrasi instans DTS

Solusi ini melakukan migrasi seluruh instans RDS ke instans baru menggunakan DTS. Solusi ini paling cocok jika Anda perlu melakukan peningkatan instans atau dapat menerima gangguan layanan sedang akibat pergantian titik akhir.

1. Ekspor semua skrip skema dari instans sumber. Pada setiap skrip, ganti ENGINE=TokuDB dengan ENGINE=InnoDB. Contohnya: Ubah:

   CREATE TABLE t1 (id INT, name VARCHAR(10)) ENGINE=TokuDB;

   Kepada:

   CREATE TABLE t1 (id INT, name VARCHAR(10)) ENGINE=InnoDB;

2. Buat instans RDS baru dan gunakan skrip yang telah dimodifikasi untuk membuat database dan tabel. Untuk detailnya, lihat Buat instans ApsaraDB RDS for MySQL.

3. Gunakan DTS untuk melakukan migrasi data dari instans sumber ke instans baru. Untuk detailnya, lihat Konfigurasi sinkronisasi data satu arah antar instans ApsaraDB RDS for MySQL.

   Saat mengonfigurasi tugas DTS, pilih hanya Initial Full Data Synchronization.

   

4. Setelah delay sinkronisasi mencapai 0, perbarui string koneksi aplikasi Anda agar mengarah ke titik akhir instans baru.

Setelah migrasi

Setelah menyelesaikan salah satu solusi di atas, perbarui parameter default_storage_engine pada instans RDS Anda menjadi InnoDB.

Untuk memperbarui parameter tersebut, buka Konsol RDS, navigasi ke Parameters, dan atur default_storage_engine menjadi InnoDB.