Online partitioning feature (rds_online_migrate) - ApsaraDB RDS

L'extension rds_online_migrate pour ApsaraDB RDS for PostgreSQL propose une fonctionnalité de partitionnement en ligne. Elle permet de convertir une table standard en table partitionnée.

Contexte

Le volume de vos données augmente avec la croissance de votre activité. Dans certains cas, il est nécessaire de convertir une table standard en table partitionnée. Or, PostgreSQL natif ne propose pas de conversion en ligne. Pour simplifier les opérations et la maintenance (O&M) et réduire l'impact du partitionnement sur votre activité, ApsaraDB RDS for PostgreSQL met à disposition une fonctionnalité de partitionnement en ligne.

Applicabilité

Votre instance ApsaraDB RDS for PostgreSQL doit répondre aux exigences suivantes :

Version majeure : 13 ou ultérieure.
Version mineure du moteur : 20251130 ou ultérieure.

Précautions

Avant de procéder au partitionnement en ligne, examinez les informations ci-dessous afin de garantir la sécurité des données et le succès de l'opération.

Préparatifs
- Sauvegarde et tests : Avant toute intervention, assurez-vous de disposer d'une sauvegarde complète valide. Nous vous recommandons également d'effectuer des tests approfondis dans un environnement hors production.
- Planification de l'espace de stockage : Lors du processus de partitionnement en ligne, le système crée une nouvelle table pour la migration des données. Vous devez donc réserver un espace de stockage équivalent au moins au double de la taille totale de la table source et de tous ses index.
- Paramètres de la base de données : Cette fonctionnalité repose sur le décodage logique (Logical Decoding). Définissez le paramètre wal_level sur logical. De plus, pour exécuter plusieurs tâches de partitionnement en parallèle, augmentez éventuellement la valeur du paramètre max_worker_processes.
Schéma de table et exigences en matière d'autorisations
- Clé primaire ou identifiant unique : Cette fonctionnalité utilisant la réplication logique native de PostgreSQL, la table source doit posséder une PRIMARY KEY ou avoir l'attribut REPLICA IDENTITY défini.
- Autorisations utilisateur : Le compte utilisateur qui effectue l'opération doit disposer des autorisations nécessaires pour créer une publication, un subscription et un replication slot. Il doit également être autorisé à effectuer l'opération RENAME sur les tables source et de destination.
- Cohérence des autorisations : Afin d'assurer la continuité de l'activité, accordez au compte métier les mêmes autorisations sur la table partitionnée de destination que celles dont il dispose sur la table source avant la migration.
Gestion des exceptions et risques
- Opération non atomique : Cette fonctionnalité repose sur un processus scripté et ne garantit pas l'atomicité. Si le processus est interrompu par une exception, des objets internes résiduels peuvent subsister.
- Nettoyage manuel : En cas d'exception, nettoyez manuellement les enregistrements restants de la table rds_online_migrate.internal_map, ainsi que les objets publication, subscription et replication slot. Consultez le journal des erreurs et utilisez les commandes suivantes pour effectuer le nettoyage :
```
-- Clean up metadata records
DELETE FROM rds_online_migrate.internal_map WHERE src_relname = 'source_table' AND dst_relname = 'destination_table';

-- Delete the residual publication
DROP PUBLICATION publication_name;

-- Delete the residual subscription
DROP SUBSCRIPTION subscription_name;

-- Delete the residual replication slot
SELECT pg_drop_replication_slot('slot_name');
```
Impacts potentiels de l'opération RENAME
- Reconstruction des objets associés : Une fois l'opération RENAME terminée, reconstruisez manuellement toutes les vues, déclencheurs et contraintes de clé étrangère qui dépendent de la table d'origine.
- Impact sur la réplication logique : Si la table source fait partie d'une autre tâche de réplication logique, l'opération RENAME risque d'interrompre cette tâche. Une fois l'opération terminée, rajoutez la nouvelle table (la table de destination d'origine) à la publication correspondante.
Scénario étendu
- Cette fonctionnalité prend également en charge le repartitionnement en ligne des tables partitionnées existantes.

Exemple d'utilisation

L'exemple suivant illustre la conversion en ligne d'une table standard nommée public.test en table partitionnée.

1. Configurez les paramètres de la base de données

La fonctionnalité rds_online_migrate repose sur le décodage logique (Logical Decoding). Dans la console ApsaraDB RDS, définissez le paramètre wal_level sur logical.

2. Préparez la table source et les données

Créez une table standard nommée public.test qui servira de table source pour la conversion. Insérez ensuite un million de lignes de données de test afin de simuler un scénario métier réel.

-- Create the source table
CREATE TABLE public.test(id int4 PRIMARY KEY, info text);

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

3. Installez l'extension

Créez l'extension rds_online_migrate dans la base de données où vous souhaitez effectuer l'opération.

CREATE EXTENSION rds_online_migrate;

4. Créez la table partitionnée de destination

Créez une table partitionnée de destination nommée public.test_p ayant la même structure que la table source. Cette table de destination doit se trouver dans le même schéma (namespace) que la table source. Cet exemple crée une table partitionnée par hachage de l'ID, avec quatre sous-partitions.

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. Effectuez la conversion en ligne

Appelez la fonction rds_online_migrate.rewrite_table pour démarrer le processus de partitionnement en ligne. Le premier paramètre de la fonction correspond au nom de la table source, et le second au nom de la table partitionnée de destination. La fonction renvoie t pour indiquer que l'exécution a réussi.

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

6. Vérifiez le résultat de la conversion

Une fois l'opération réussie, la fonction permute automatiquement les noms de table afin d'assurer une transition transparente pour votre activité :

La table d'origine public.test est renommée en public.test_rds_bkp. Cette table sert de sauvegarde des données pour une vérification ultérieure et peut être supprimée à votre convenance.
La table partitionnée de destination public.test_p est renommée en public.test et devient la nouvelle table active.

Ensuite, vérifiez le résultat en suivant les étapes ci-dessous :

Vérifiez le schéma de la table Utilisez la commande \d pour afficher la liste des relations. Confirmez que les noms de table ont été permutés comme prévu et que la nouvelle table test est bien une 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)

Vérifiez l'intégrité des données Interrogez le nombre de lignes dans la nouvelle table, la table de sauvegarde et chaque partition afin de vous assurer que la migration des données est complète et que les données sont correctement distribuées.
1. Interrogez le nombre total de lignes dans la table de sauvegarde. Le comptage doit être identique à celui effectué avant la migration.
```
SELECT count(*) FROM public.test_rds_bkp;
-- Expected output: 1000000
```
2. Interrogez le nombre total de lignes dans la nouvelle table partitionnée. Le comptage doit correspondre à celui de la table de sauvegarde.
```
SELECT count(*) FROM public.test;
-- Expected output: 1000000
```
3. Interrogez le nombre de lignes dans chaque partition pour vérifier que les données ont été distribuées dans les tables enfants selon la règle de hachage.
```
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
```