Operasi DDL yang membangun ulang indeks B-tree—seperti menambahkan primary key, menambahkan secondary index, atau menjalankan OPTIMIZE TABLE—menghasilkan volume besar log redo. Di node primary, penulisan log redo ini menjadi bottleneck yang memperlambat eksekusi DDL. Di node read-only, penguraian dan penerapan log redo yang sama dapat menyebabkan keterlambatan replikasi parah dan, dalam beban kerja DDL konkuren, membuat node read-only tidak tersedia.
Optimasi replikasi fisik DDL mengatasi kedua masalah tersebut dengan mengoptimalkan jalur penulisan log redo di node primary dan jalur penerapan log redo di node read-only. Dengan fitur ini diaktifkan, waktu untuk menambahkan primary key di node primary turun menjadi sekitar 20,6% dari garis dasar, dan latensi replikasi di node read-only turun menjadi sekitar 0,4% dari garis dasar.
Prasyarat
Sebelum memulai, pastikan kluster memenuhi salah satu persyaratan versi berikut. Untuk memeriksa versi saat ini, lihat Versi engine.
PolarDB for MySQL 8.0.1 dengan versi revisi 8.0.1.1.10 atau lebih baru
PolarDB for MySQL 5.7 dengan versi revisi 5.7.1.0.10 atau lebih baru
Cara kerja
PolarDB memisahkan komputasi dari penyimpanan. Node primary dan node read-only berbagi data dasar yang sama, dan replikasi fisik menjaga konsistensi di antara keduanya dengan menyebarkan log redo alih-alih log biner. Pendekatan ini juga mengurangi overhead I/O akibat operasi fsync pada log biner.
InnoDB menyimpan data dalam indeks B-tree. Operasi DDL yang membuat atau membangun ulang indeks tersebut—seperti menambahkan primary key, membuat secondary index, atau menjalankan OPTIMIZE TABLE—menghasilkan sejumlah besar log redo. Tanpa optimasi:
Penulisan log redo menjadi bottleneck pada jalur eksekusi DDL di node primary.
Node read-only harus mengurai dan menerapkan semua log redo tersebut sebelum dapat melayani pembacaan konsisten, menyebabkan keterlambatan replikasi yang dapat berujung pada ketidaktersediaan node dalam beban kerja DDL konkuren.
Optimasi replikasi fisik DDL menghilangkan bottleneck tersebut dengan membuat penulisan log redo di node primary lebih efisien dan mengurangi beban kerja yang harus dilakukan oleh node read-only untuk menerapkan log redo yang dihasilkan DDL.
Batasan
Operasi DDL yang didukung: hanya pembuatan primary key dan secondary index. Indeks full-text dan indeks spasial tidak didukung.
Operasi DDL yang hanya mengubah metadata seperti
RENAME TABLEtidak memerlukan fitur ini karena mengonsumsi sumber daya minimal dan secara default sudah cepat.Tidak didukung pada PolarDB for MySQL 8.0.2 atau 5.6.
Aktifkan optimasi replikasi fisik DDL
Atur parameter berikut di tingkat global untuk mengaktifkan fitur ini.
| Parameter | Tingkat | Nilai default | Deskripsi |
|---|---|---|---|
innodb_bulk_load_page_grained_redo_enable | Global | OFF | Mengontrol optimasi replikasi fisik DDL. Atur ke ON untuk mengaktifkan. |
Hasil kinerja
Pengujian berikut dijalankan pada kluster PolarDB for MySQL 8.0 dengan satu node primary dan satu node read-only (16 core CPU, memori 128 GB, penyimpanan 50 TB).
Persiapan pengujian
Skema:
CREATE TABLE t0(a INT PRIMARY KEY, b INT) ENGINE=InnoDB;Data: Tabel dengan 1 juta, 10 juta, 100 juta, dan 1 miliar baris, diisi dengan nilai acak:
DELIMITER //
CREATE PROCEDURE populate_t0()
BEGIN
DECLARE i int DEFAULT 1;
WHILE (i <= $table_size) DO
INSERT INTO t0 VALUES (i, 1000000 * RAND());
SET i = i + 1;
END WHILE;
END //
DELIMITER ;
CALL populate_t0();Ganti$table_sizedengan jumlah baris yang akan dimasukkan, misalnya1000000.
Operasi DDL yang diuji:
ADD PRIMARY KEYADD INDEX(secondary index)OPTIMIZE TABLE
Pengujian 1: Waktu eksekusi DDL di node primary
Bandingkan waktu (dalam detik) untuk ADD PRIMARY KEY dan OPTIMIZE TABLE pada berbagai ukuran tabel, dengan innodb_bulk_load_page_grained_redo_enable diatur ke ON dibandingkan dengan OFF.
Tambahkan primary key:

Optimalkan tabel:

Pengujian 2: Kombinasi dengan parallel DDL
Bandingkan waktu (dalam detik) untuk ADD INDEX pada tabel berisi 1 miliar baris dengan jumlah thread berbeda (innodb_polar_parallel_ddl_threads diatur ke 1, 2, 4, 8, 16, dan 32), dengan innodb_bulk_load_page_grained_redo_enable diatur ke ON dibandingkan dengan OFF.
Dengan parallel DDL diaktifkan (innodb_polar_use_sample_sort dan innodb_polar_use_parallel_bulk_load keduanya diaktifkan):

Dengan parallel DDL dinonaktifkan (innodb_polar_use_sample_sort dan innodb_polar_use_parallel_bulk_load keduanya dinonaktifkan):

Untuk informasi lebih lanjut tentang parameter parallel DDL, lihat Parallel DDL.
Pengujian 3: Stabilitas node read-only dalam beban kerja DDL konkuren
Uji status node read-only, penggunaan CPU, penggunaan memori, IOPS, dan latensi replikasi saat node primary menjalankan 1, 2, 4, 6, dan 8 operasi DDL konkuren pada tabel berisi 1 miliar baris.
Fitur diaktifkan (`innodb_bulk_load_page_grained_redo_enable = ON`):
| Jumlah operasi DDL konkuren | 1 | 2 | 4 | 6 | 8 |
|---|---|---|---|---|---|
| Status node read-only | Normal | Normal | Normal | Normal | Normal |
| Penggunaan CPU puncak (%) | 1,86 | 1,71 | 1,76 | 2,25 | 2,36 |
| Penggunaan memori puncak (%) | 10,37 | 10,80 | 10,88 | 11 | 11,1 |
| Read IOPS (baca per detik) | 10965 | 10762 | 10305 | 10611 | 10751 |
| Latensi replikasi puncak (dtk) | 0 | 0,73 | 0,87 | 0,93 | 0,03 |
Fitur dinonaktifkan (`innodb_bulk_load_page_grained_redo_enable = OFF`):
Untuk 4 operasi DDL konkuren, data yang ditampilkan adalah sebelum node read-only menjadi tidak tersedia. Tanda hubung (-) menunjukkan operasi DDL gagal pada tingkat konkurensi tersebut dan tidak ada hasil yang dikembalikan.
| Jumlah operasi DDL konkuren | 1 | 2 | 4 | 6 | 8 |
|---|---|---|---|---|---|
| Status node read-only | Normal | Normal | Tidak tersedia | Tidak tersedia | Tidak tersedia |
| Penggunaan CPU puncak (%) | 4,2 | 9,5 | 10,3 | - | - |
| Penggunaan memori puncak (%) | 22,15 | 23,55 | 68,61 | - | - |
| Read IOPS (baca per detik) | 9243 | 7578 | 7669 | - | - |
| Latensi replikasi puncak (dtk) | 0,8 | 14,67 | 211 | - | - |
Dengan fitur dinonaktifkan, node read-only menjadi tidak tersedia pada 4 atau lebih operasi DDL konkuren dan latensi replikasi melonjak hingga 211 detik dalam kondisi 4 operasi konkuren. Dengan fitur diaktifkan, node tetap stabil di semua tingkat konkurensi yang diuji dengan latensi replikasi di bawah 1 detik.
Hubungi kami
Jika Anda memiliki pertanyaan tentang operasi DDL, silakan hubungi dukungan teknis.
Langkah selanjutnya
Parallel DDL — Gunakan thread paralel untuk lebih mengurangi waktu eksekusi DDL di node primary.
Engine versions — Periksa versi revisi kluster Anda saat ini.