PolarDB:FAQ DDL

Bagaimana cara menaikkan batas jumlah database di PolarDB-X 2.0?

PolarDB-X 2.0 secara default mengizinkan maksimal 32 database logis. Untuk menaikkan batas ini, lakukan koneksi menggunakan akun dengan hak istimewa tinggi dan jalankan:

SET GLOBAL MAX_LOGICAL_DB_COUNT=64;

Bagaimana cara mengidentifikasi operasi DDL yang tidak normal di PolarDB-X 2.0?

Jalankan pernyataan berikut untuk memeriksa aktivitas DDL yang macet atau tidak normal:

SHOW FULL DDL;
SHOW FULL physical_processlist WHERE info !='';

Berapa banyak catatan yang dapat saya masukkan dalam satu operasi batch?

Ukuran batch yang aman bergantung pada ukuran baris Anda dan pengaturan max_allowed_packet.

Perkirakan ukuran baris Anda

Hitung jumlah maksimum byte per baris menggunakan ukuran penyimpanan InnoDB berikut:

Untuk tipe objek besar seperti TEXT, BLOB, LONGTEXT, dan lainnya, evaluasi setiap bidang secara terpisah berdasarkan penggunaan maksimum aktualnya. Misalnya, Group_ID VARCHAR(1024) yang hanya menyimpan satu digit tetap dihitung sebagai 1.024 byte dalam perkiraan ukuran baris maksimum Anda.

Hitung ukuran batch

Menggunakan contoh baris sebesar 1.913 byte (8+8+8+8+8+8+255+255+255+1.024+4+64+8):

• Pada 1 MB: (1.024 × 1.024) / 1.913 ≈ 548 catatan. Batasi batch di bawah 500 agar tidak melebihi batas berdasarkan metode penyisipan batch 16 MB pada lapisan komputasi PolarDB-X CN.

• Pada max_allowed_packet=16M: 500 × 16 = 8.000 catatan merupakan batas atas yang aman.

Rekomendasi parameter

• Atur max_allowed_packet ke nilai maksimumnya.

• Atur innodb_log_buffer_size antara 32M hingga 128M. Uji berbagai nilai untuk menemukan waktu respons optimal bagi workload Anda—hal ini mencegah InnoDB melakukan flush log ke disk terlalu sering sebelum transaksi dikomit.

Faktor lain yang memengaruhi performa penyisipan

• Ukuran kolam buffer InnoDB

• IOPS disk dan lebar pita jaringan (dalam penerapan database terdistribusi)

• Perilaku flush buffer redo log (innodb_log_buffer_size)

Error DDL: Tabel GSI tidak bersifat public

Penyebab:

Global Secondary Index (GSI) berada dalam keadaan tidak valid. Jalankan SHOW GLOBAL INDEX FROM <table_name>; untuk memeriksa status indeks tersebut. Anda hanya dapat melakukan operasi DDL pada tabel target ketika GSI berada dalam status PUBLIC atau ABSENT. Status lain menunjukkan bahwa GSI masih dalam proses pembuatan, sehingga memblokir operasi DDL lainnya.

Solusi:

1. Pertama, jalankan SHOW DDL; untuk memeriksa apakah ada operasi DDL sisa yang mungkin memblokir operasi saat ini.

2. Jika terdapat operasi DDL sisa, tunggu hingga selesai. Jika status yang dikembalikan oleh SHOW GLOBAL INDEX bukan PUBLIC atau ABSENT, pertimbangkan untuk membatalkan pembuatan GSI dengan menjalankan CANCEL DDL <JOB_ID>;. Kemudian, jalankan ulang operasi DDL tersebut.

   mysql> show ddl;
   +--------+---------------+-------------+--------+-------------+--------+-------------------------+---------------------------+----------+------------------------+---------------------------+
   | JOB_ID | OBJECT_SCHEMA | OBJECT_NAME | ENGINE | DDL_TYPE    | STATE  | TOTAL_BACKFILL_PROGRESS | CURRENT_PHY_DDL_PROGRESS | PROGRESS | FASTCHECKER_TASK_NUM | FASTCHECKER_TASK_FINISHED |
   | ELAPSED_TIME(MS) | PHY_PROCESS | CANCELABLE |
   +--------+---------------+-------------+--------+-------------+--------+-------------------------+---------------------------+----------+------------------------+---------------------------+
   | xxx    | xxx           | test_ck     | t_order1 | DAG       | ALTER_TABLE | PAUSED | -                     |                           | 100%     |                      | 32%                       | 0                | 0           |
   | 2.529  | 894           |             |         | true       |
   +--------+---------------+-------------+--------+-------------+--------+-------------------------+---------------------------+----------+------------------------+---------------------------+
   1 row in set (0.03 sec)
   mysql> cancel ddl xxx;
   Query OK, 1 row affected (3.23 sec)
   mysql> ALTER TABLE t_order1 PARTITION BY KEY(`ORDER_NO`) PARTITIONS 8;
   Query OK, 0 rows affected (5.54 sec)

Cara memulihkan dari kegagalan sebagian shard setelah ALTER TABLE MODIFY COLUMN atau CHANGE COLUMN

Di PolarDB-X, operasi DDL MODIFY COLUMN dapat berhasil pada beberapa shard namun gagal pada yang lain jika data di shard yang gagal melanggar batasan kolom baru. Contohnya:

-- Buat tabel yang dipartisi di 32 shardCREATE TABLE `t1` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `c2` varchar(16) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4
PARTITION BY KEY(`id`)
PARTITIONS 32;

INSERT INTO t1 VALUES (1, "1");
INSERT INTO t1 VALUES (2, "abc");

-- Dalam SQL_MODE strict, ini gagal karena "abc" bukan nilai integer yang validSET sql_mode="strict_trans_tables";
ALTER TABLE t1 MODIFY COLUMN c2 INT;

Pesan error akan tampak seperti:

...Not all physical DDLs have been executed successfully: 32 expected, 31 done, 1 failed...Incorrect integer value...

PolarDB-X menyediakan dua jalur pemulihan: eksekusi maju (perbaiki data dan lanjutkan) dan eksekusi balik (kembalikan perubahan).