Dear hackers,
I found another use-case for LRG. It might be helpful for migration.
LRG for migration
------------------------------------------
LRG may be helpful for machine migration, OS upgrade,
or PostgreSQL itself upgrade.
Assumes that users want to migrate database to other environment,
e.g., PG16 on RHEL7 to PG18 on RHEL8.
Users must copy all data into new server and catchup all changes.
In this case streaming replication cannot be used
because it requires same OS and same PostgreSQL major version.
Moreover, it is desirable to be able to return to the original environment at any time
in case of application or other environmental deficiencies.
Operation steps with LRG
------------------------------------------
LRG is appropriate for the situation. Following lines are the workflow that users must do:
1. Copy the table definition to the newer node(PG18), via pg_dump/pg_restore
2. Execute lrg_create() in the older node(PG16)
3. Execute lrg_node_attach() in PG18
=== data will be shared here===
4. Change the connection of the user application to PG18
5. Check whether ERROR is raised or not. If some ERRORs are raised,
users can change back the connection to PG16.
6. Remove the created node group if application works well.
These operations may reduce system downtime
due to incompatibilities associated with version upgrades.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED