Topik ini menjelaskan fitur pemeliharaan partisi online di PolarDB.
Dalam Edisi Komunitas MySQL, operasi bahasa manipulasi data (DML) dan operasi bahasa definisi data (DDL) tidak dapat dilakukan secara bersamaan. Oleh karena itu, operasi DDL hanya dapat dilakukan selama jam sepi untuk meminimalkan dampaknya terhadap operasi DML. Namun, dalam penggunaan aktual, partisi dibuat dan dihapus dengan laju yang relatif tinggi. Pembatasan pada operasi DDL mengurangi ketersediaan tabel partisi. Fitur pemeliharaan partisi online meningkatkan kemampuan paralel dari operasi DML dan beberapa operasi DDL, khususnya operasi DDL yang digunakan untuk membuat dan menghapus partisi. Hal ini membantu meningkatkan performa tugas roll-in dan roll-out pada tabel partisi. Gambar berikut mengilustrasikan fitur pemeliharaan partisi online.
Prasyarat
Sebuah kluster PolarDB for MySQL 8.0 dengan versi revisi 8.0.2.2.0 atau lebih baru. Untuk informasi lebih lanjut tentang cara melihat versi kluster Anda, lihat Kueri Versi Mesin.
Parameter partition_level_mdl_enabled disetel ke ON. Untuk informasi lebih lanjut, lihat Konfigurasikan Parameter Kluster dan Node.
Parameter
Tingkat
Deskripsi
partition_level_mdl_enabled
Global
Menentukan apakah akan mengaktifkan fitur kunci metadata tingkat partisi (MDL). Nilai valid:
ON: mengaktifkan fitur MDL tingkat partisi.
OFF: menonaktifkan fitur MDL tingkat partisi.
CatatanAnda harus me-restart kluster untuk memvalidasi modifikasi.
Tingkat isolasi global dari parameter transaction_isolation harus disetel ke READ-COMMITTED. Untuk informasi lebih lanjut, lihat Konfigurasikan Parameter Kluster dan Node.
Batasan
Fitur pemeliharaan partisi online hanya berlaku untuk operasi ADD PARTITION untuk partisi rentang dan partisi daftar, serta operasi DROP PARTITION, EXCHANGE PARTITION, REBUILD PARTITION, dan REORGANIZE PARTITION. Fitur pemeliharaan partisi online untuk operasi DDL lainnya akan tersedia segera.
Tingkat isolasi juga dapat disetel ke sesi. Jika transaction-isolation disetel ke REPEATABLE-READ atau lebih tinggi, pesan kesalahan "
ERROR HY000: Definisi tabel telah berubah, silakan ulangi transaksi" mungkin dilaporkan ketika operasi DDL dilakukan secara bersamaan. Ini normal. Alasannya adalah bahwa partisi baru yang dibuat oleh operasi DDL diakses. Anda dapat mengeksekusi transaksi lagi untuk menyelesaikan masalah tersebut.
Penggunaan dan contoh
Fitur pemeliharaan partisi online menghindari dan mengurangi efek dari pemeliharaan partisi terhadap akses data. Anda dapat melakukan pemeliharaan partisi kapan pun Anda mau. Contoh berikut mengilustrasikan bagaimana fitur ini dapat digunakan.
# Tampilkan struktur tabel tr pada klien 1.
SHOW CREATE TABLE tr\G
*************************** 1. row ***************************
Table: tr
Create Table: CREATE TABLE `tr` (
`id` int(11) DEFAULT NULL,
`name` varchar(50) DEFAULT NULL,
`purchased` date DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!50100 PARTITION BY RANGE (year(`purchased`))
(PARTITION p0 VALUES LESS THAN (1990) ENGINE = InnoDB,
PARTITION p1 VALUES LESS THAN (1995) ENGINE = InnoDB,
PARTITION p2 VALUES LESS THAN (2000) ENGINE = InnoDB,
PARTITION p3 VALUES LESS THAN (2005) ENGINE = InnoDB,
PARTITION p4 VALUES LESS THAN (2010) ENGINE = InnoDB,
PARTITION p5 VALUES LESS THAN (2015) ENGINE = InnoDB) */
1 row in set (0.00 sec)
# Aktifkan transaksi pada klien 1.
BEGIN;
Query OK, 0 rows affected (0.01 sec)
SELECT * FROM tr WHERE purchased >= '2010-01-01';
+------+----------------+------------+
| id | name | purchased |
+------+----------------+------------+
| 5 | exercise bike | 2014-05-09 |
| 7 | espresso maker | 2011-11-22 |
+------+----------------+------------+
2 rows in set (0.01 sec)
# Buat partisi baru pada klien 2.
ALTER TABLE tr ADD PARTITION (PARTITION p6 VALUES LESS THAN (2020));
INSERT INTO tr VALUES (11, 'hope', '2017-11-04'), (12, 'carmen', '2018-06-08');
# Dalam transaksi yang sama, klien 1 dapat mengakses data dari partisi baru.
SELECT * FROM tr WHERE purchased >= '2010-01-01';
+------+----------------+------------+
| id | name | purchased |
+------+----------------+------------+
| 5 | exercise bike | 2014-05-09 |
| 7 | espresso maker | 2011-11-22 |
| 11 | hope | 2017-11-04 |
| 12 | carmen | 2018-06-08 |
+------+----------------+------------+
4 rows in set (0.00 sec)
# Hapus partisi lama pada klien 2.
ALTER TABLE tr DROP PARTITION p0;
# Tampilkan definisi tabel pada klien 1. Hasilnya menunjukkan bahwa partisi baru p6 ada dan partisi lama p0 dihapus.
SHOW CREATE TABLE tr\G
*************************** 1. row ***************************
Table: tr
Create Table: CREATE TABLE `tr` (
`id` int(11) DEFAULT NULL,
`name` varchar(50) DEFAULT NULL,
`purchased` date DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!50100 PARTITION BY RANGE (year(`purchased`))
(PARTITION p1 VALUES LESS THAN (1995) ENGINE = InnoDB,
PARTITION p2 VALUES LESS THAN (2000) ENGINE = InnoDB,
PARTITION p3 VALUES LESS THAN (2005) ENGINE = InnoDB,
PARTITION p4 VALUES LESS THAN (2010) ENGINE = InnoDB,
PARTITION p5 VALUES LESS THAN (2015) ENGINE = InnoDB,
PARTITION p6 VALUES LESS THAN (2020) ENGINE = InnoDB) */
1 row in set (0.00 sec)
# Commit transaksi pada klien 1.
COMMIT;Perbandingan performa
Bagian berikut menjelaskan skenario paling umum untuk interaksi operasi DML dan DDL: operasi DDL yang diblokir oleh transaksi jangka panjang dan operasi DDL yang memakan waktu. Performa dibandingkan untuk kasus di mana fitur pemeliharaan partisi online diaktifkan dan dinonaktifkan.
Skenario 1: Operasi DDL yang diblokir oleh transaksi jangka panjang
Dalam skenario ini, sebuah operasi DDL dilakukan pada tabel partisi. Operasi DDL diblokir karena transaksi jangka panjang belum dikomit. Operasi DDL yang diblokir memblokir semua operasi DML baru, menyebabkan lalu lintas database turun menjadi nol.
Gambar di atas menunjukkan bahwa lalu lintas sysbench di tabel dengan cepat turun menjadi nol, dan database sepenuhnya tidak tersedia ketika fitur pemeliharaan partisi online dinonaktifkan dan operasi DDL dilakukan. Database hanya pulih setelah Anda membatalkan operasi DDL atau mengomiti semua transaksi jangka panjang. Setelah fitur pemeliharaan partisi online diaktifkan, efek berikut diamati:
Dalam kondisi normal, throughput sysbench persis sama dengan saat fitur pemeliharaan partisi online dinonaktifkan. Ini menunjukkan bahwa performa tidak terpengaruh ketika fitur pemeliharaan partisi online diaktifkan.
Transaksi jangka panjang yang belum dikomit tidak memblokir operasi DDL. Lalu lintas DML pada database stabil dan hampir tidak terpengaruh.
Skenario 2: Operasi DDL yang memakan waktu
Dalam skenario ini, meskipun operasi DDL tidak diblokir oleh pernyataan SQL lainnya, throughput DML dipengaruhi oleh operasi DDL yang memakan waktu.
Dalam gambar di atas, ketika fitur pemeliharaan partisi online dinonaktifkan, operasi DDL yang memakan waktu menyebabkan jittering parah pada throughput DML. Setelah fitur pemeliharaan partisi online diaktifkan, operasi DDL yang memakan waktu memiliki sedikit dampak pada throughput DML.
Lihat status MDL
Fitur pemeliharaan partisi online menggunakan MDL tingkat partisi untuk mengurangi granularitas kunci selama operasi DML dan DDL dan dengan demikian meningkatkan konkurensi. Ketika operasi DDL dilakukan, Anda dapat melihat status MDL pada tingkat partisi dari tabel performance_schema.metadata_locks. Contoh kode berikut memberikan contoh:
# Tampilkan struktur tabel tr pada klien 1.
SHOW CREATE TABLE tr\G
*************************** 1. row ***************************
Table: tr
Create Table: CREATE TABLE `tr` (
`id` int(11) DEFAULT NULL,
`name` varchar(50) DEFAULT NULL,
`purchased` date DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!50100 PARTITION BY RANGE (year(`purchased`))
(PARTITION p0 VALUES LESS THAN (1990) ENGINE = InnoDB,
PARTITION p1 VALUES LESS THAN (1995) ENGINE = InnoDB,
PARTITION p2 VALUES LESS THAN (2000) ENGINE = InnoDB,
PARTITION p3 VALUES LESS THAN (2005) ENGINE = InnoDB,
PARTITION p4 VALUES LESS THAN (2010) ENGINE = InnoDB,
PARTITION p5 VALUES LESS THAN (2015) ENGINE = InnoDB) */
1 row in set (0.00 sec)
# Aktifkan transaksi pada klien 1.
BEGIN;
Query OK, 0 rows affected (0.01 sec)
SELECT * FROM tr WHERE purchased >= '2010-01-01';
+------+----------------+------------+
| id | name | purchased |
+------+----------------+------------+
| 5 | exercise bike | 2014-05-09 |
| 7 | espresso maker | 2011-11-22 |
+------+----------------+------------+
2 rows in set (0.01 sec)
# Lihat status MDL pada klien 1.
SELECT * FROM performance_schema.metadata_locks;
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | COLUMN_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| TABLE | test | tr | NULL | 140734887898944 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6759 | 67 | 17 |
| PARTITION | test | tr | p5 | 140734887896704 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6502 | 67 | 17 |
| TABLE | performance_schema | metadata_locks | NULL | 140734879511488 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6759 | 68 | 4 |
| SCHEMA | performance_schema | NULL | NULL | 140734879511648 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | dd_schema.cc:108 | 68 | 4 |
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
4 rows in set (0.02 sec)
# Hasil pada klien 1 menunjukkan bahwa kunci SHARED_READ pada tingkat tabel tr diperoleh dan kunci SHARED_READ pada tingkat partisi p5 diakses setelah pemangkasan. Kemudian, coba hapus partisi p5 pada klien 2.
ALTER TABLE tr DROP PARTITION p5;
# Operasi penghapusan di atas memasuki keadaan menunggu karena partisi p5 sedang diakses oleh klien 1. Anda dapat mengeksekusi pernyataan berikut untuk memeriksa apakah thread sedang menunggu MDL tingkat partisi.
SHOW PROCESSLIST;
+----+-----------------+-----------+------+---------+------+-------------------------------------+----------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+-----------+------+---------+------+-------------------------------------+----------------------------------+
| 4 | event_scheduler | localhost | NULL | Daemon | 1550 | Waiting on empty queue | NULL |
| 8 | root | localhost | test | Sleep | 426 | | NULL |
| 9 | root | localhost | NULL | Query | 0 | starting | SHOW PROCESSLIST |
| 10 | root | localhost | test | Query | 10 | Waiting for partition metadata lock | ALTER TABLE tr DROP PARTITION p5 |
+----+-----------------+-----------+------+---------+------+-------------------------------------+----------------------------------+
4 rows in set (0.00 sec)
# Partisi p5 dihapus dari klien 2 setelah transaksi dikomit pada klien 1.Lihat jumlah tugas pemeliharaan partisi online
Anda dapat menggunakan parameter STATUS Online_altered_partition untuk melihat jumlah tugas pemeliharaan partisi online. Contoh:
SHOW STATUS LIKE 'Online_altered_partition';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Online_altered_partition | 2565 |
+--------------------------+-------+
1 row in set (0.00 sec)