Fitur partisi online (rds_online_migrate) - ApsaraDB RDS

Ekstensi rds_online_migrate untuk ApsaraDB RDS for PostgreSQL menyediakan fitur partisi online yang memungkinkan Anda mengonversi tabel standar menjadi tabel partisi.

Latar Belakang

Seiring pertumbuhan bisnis Anda, volume data meningkat. Dalam skenario tertentu, Anda mungkin perlu mengonversi tabel standar menjadi tabel partisi. Namun, PostgreSQL native tidak menyediakan fitur konversi online. Untuk menyederhanakan operasi dan pemeliharaan (O&M) serta meminimalkan dampak partisi terhadap bisnis, ApsaraDB RDS for PostgreSQL menyediakan fitur partisi online.

Penerapan

Instans ApsaraDB RDS for PostgreSQL Anda harus memenuhi persyaratan berikut:

Versi utama: 13 atau lebih baru.
Versi mesin minor: 20251130 atau lebih baru.

Perhatian

Sebelum melakukan operasi partisi online, tinjau informasi berikut untuk memastikan keamanan data dan keberhasilan operasi.

Persiapan
- Cadangan dan pengujian: Sebelum melakukan operasi apa pun, pastikan Anda memiliki cadangan penuh yang valid. Kami juga menyarankan agar Anda melakukan pengujian dan verifikasi menyeluruh di lingkungan non-produksi.
- Perencanaan storage space: Selama proses partisi online, sistem membuat tabel baru untuk migrasi data. Oleh karena itu, Anda harus menyediakan storage space minimal sebesar dua kali ukuran total tabel sumber beserta seluruh indeksnya.
- Pengaturan parameter database: Fitur ini bergantung pada Logical Decoding. Anda harus mengatur parameter wal_level ke nilai logical. Selain itu, untuk menjalankan beberapa task partisi secara paralel, Anda mungkin perlu menaikkan nilai parameter max_worker_processes.
Persyaratan skema tabel dan izin
- Kunci primer atau identitas replikasi: Karena fitur ini menggunakan replikasi logis native PostgreSQL, tabel sumber harus memiliki PRIMARY KEY atau telah mengatur REPLICA IDENTITY.
- Izin pengguna: Akun pengguna yang menjalankan operasi harus memiliki izin untuk membuat publication, subscription, dan replication slot. Akun tersebut juga harus memiliki izin untuk menjalankan operasi RENAME pada tabel sumber dan tujuan.
- Konsistensi izin: Untuk memastikan kelangsungan bisnis, berikan akun bisnis izin yang sama pada tabel partisi tujuan seperti yang dimilikinya pada tabel sumber sebelum migrasi.
Penanganan pengecualian dan risiko
- Operasi non-atomik: Fitur ini merupakan proses berbasis skrip dan tidak bersifat atomik. Jika proses terganggu oleh pengecualian, objek internal sisa mungkin tetap ada.
- Pembersihan manual: Jika terjadi pengecualian, Anda mungkin perlu membersihkan secara manual catatan tabel rds_online_migrate.internal_map, serta objek publication, subscription, dan replication slot yang tersisa. Rujuk log error dan gunakan perintah berikut untuk melakukan pembersihan:
```
-- Bersihkan catatan metadata
DELETE FROM rds_online_migrate.internal_map WHERE src_relname = 'source_table' AND dst_relname = 'destination_table';

-- Hapus publication sisa
DROP PUBLICATION publication_name;

-- Hapus subscription sisa
DROP SUBSCRIPTION subscription_name;

-- Hapus replication slot sisa
SELECT pg_drop_replication_slot('slot_name');
```
Dampak potensial dari operasi RENAME
- Menulis ulang objek terkait: Setelah operasi RENAME selesai, Anda harus menulis ulang secara manual Tampilan, Pemicu, dan kendala kunci asing yang bergantung pada tabel asli.
- Dampak pada replikasi logis: Jika tabel sumber merupakan bagian dari task replikasi logis lain, operasi RENAME dapat mengganggu task replikasi tersebut. Setelah operasi selesai, tambahkan kembali tabel baru (tabel tujuan asli) ke dalam publication yang sesuai.
Skenario lanjutan
- Fitur ini juga mendukung repartisi online pada tabel partisi yang sudah ada.

Contoh penggunaan

Contoh berikut menunjukkan cara mengonversi tabel standar bernama public.test menjadi tabel partisi secara online.

1. Konfigurasikan parameter database

Fitur rds_online_migrate bergantung pada Logical Decoding. Di Konsol ApsaraDB RDS, atur parameter wal_level ke nilai logical.

2. Siapkan tabel sumber dan data

Buat tabel standar bernama public.test sebagai tabel sumber untuk konversi. Kemudian, masukkan satu juta baris data uji untuk mensimulasikan skenario bisnis nyata.

-- Buat tabel sumber
CREATE TABLE public.test(id int4 PRIMARY KEY, info text);

-- Masukkan data uji
INSERT INTO public.test SELECT x, repeat(x::text, 2) FROM generate_series(1, 1000000) AS x;

3. Instal ekstensi

Buat ekstensi rds_online_migrate di database tempat Anda ingin menjalankan operasi.

CREATE EXTENSION rds_online_migrate;

4. Buat tabel partisi tujuan

Buat tabel partisi tujuan bernama public.test_p dengan struktur yang sama seperti tabel sumber. Tabel tujuan ini harus berada dalam skema (namespace) yang sama dengan tabel sumber. Contoh ini membuat tabel yang dipartisi berdasarkan hashing ID, dengan empat subpartisi.

CREATE TABLE public.test_p (LIKE test INCLUDING ALL) PARTITION BY HASH(id);
CREATE TABLE public.test_p_0 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE public.test_p_1 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE public.test_p_2 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE public.test_p_3 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 3);

5. Lakukan konversi online

Panggil fungsi rds_online_migrate.rewrite_table untuk memulai proses partisi online. Parameter pertama fungsi adalah nama tabel sumber, dan parameter kedua adalah nama tabel partisi tujuan. Fungsi ini mengembalikan t untuk menunjukkan bahwa eksekusi berhasil.

SELECT rds_online_migrate.rewrite_table('public.test', 'public.test_p');
-- Expected output:
 rewrite_table
---------------
 t
(1 row)

6. Verifikasi hasil konversi

Setelah operasi berhasil, fungsi secara otomatis menukar nama tabel untuk memastikan transisi yang mulus bagi bisnis Anda:

Tabel asli public.test diganti namanya menjadi public.test_rds_bkp. Tabel ini berfungsi sebagai cadangan data untuk verifikasi selanjutnya dan dapat dihapus sesuai kebijakan Anda.
Tabel partisi tujuan public.test_p diganti namanya menjadi public.test dan digunakan sebagai tabel baru.

Selanjutnya, verifikasi hasilnya dengan langkah-langkah berikut:

Periksa skema tabel Anda dapat menggunakan perintah \d untuk melihat daftar relasi. Pastikan nama tabel telah ditukar sesuai ekspektasi dan bahwa tabel test yang baru merupakan partitioned table.

testdb=> \d
-- Expected output:
                   List of relations
 Schema |     Name     |       Type        |   Owner
--------+--------------+-------------------+-----------
 public | test         | partitioned table | rds_super
 public | test_p_0     | table             | rds_super
 public | test_p_1     | table             | rds_super
 public | test_p_2     | table             | rds_super
 public | test_p_3     | table             | rds_super
 public | test_rds_bkp | table             | rds_super
(6 rows)

Verifikasi integritas data Anda dapat mengkueri jumlah baris di tabel baru, tabel cadangan, dan setiap partisi untuk memastikan migrasi data telah lengkap dan data didistribusikan dengan benar.
1. Kueri jumlah total baris di tabel cadangan. Jumlahnya harus sama dengan jumlah sebelum migrasi.
```
SELECT count(*) FROM public.test_rds_bkp;
-- Expected output: 1000000
```
2. Kueri jumlah total baris di tabel partisi baru. Jumlahnya harus sesuai dengan tabel cadangan.
```
SELECT count(*) FROM public.test;
-- Expected output: 1000000
```
3. Kueri jumlah baris di setiap partisi untuk memverifikasi bahwa data telah didistribusikan ke tabel anak sesuai aturan hash.
```
SELECT count(*) FROM public.test_p_0;
-- Expected output: 249589
SELECT count(*) FROM public.test_p_1;
-- Expected output: 250376
SELECT count(*) FROM public.test_p_2;
-- Expected output: 249786
SELECT count(*) FROM public.test_p_3;
-- Expected output: 250249
```