Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
postgresql_upgrade_majort_version [2020/01/20 15:36] – created andonovj | postgresql_upgrade_majort_version [2020/01/26 17:06] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 103: | Line 103: | ||
Checking for prepared transactions | Checking for prepared transactions | ||
- | ***Clusters are compatible*** | + | *Clusters are compatible* |
-bash-4.2$ | -bash-4.2$ | ||
</ | </ | ||
+ | |||
+ | From this point, we have two ways we can go. | ||
+ | * Ask pg_upgrade to copy the datafiles from old -> new location. The downtime depends the size of the DB | ||
+ | * Ask pg_upgrade to LINK the datafiles (hard links). The downtime is minimal. | ||
+ | |||
+ | Since we want to have the least downtime, we will use 2nd option | ||
+ | |||
+ | ====Stop the databases==== | ||
+ | Since we didn't start the new version. Stop the old database version: | ||
+ | |||
+ | <sxh bash> | ||
+ | -bash-4.2$ / | ||
+ | waiting for server to shut down.... done | ||
+ | server stopped | ||
+ | </ | ||
+ | |||
+ | Once stoppped, let's upgrade: | ||
+ | |||
+ | ====Link the new Version==== | ||
+ | <sxh bash> | ||
+ | -bash-4.2$ / | ||
+ | Performing Consistency Checks | ||
+ | ----------------------------- | ||
+ | Checking cluster versions | ||
+ | Checking database user is the install user ok | ||
+ | Checking database connection settings | ||
+ | Checking for prepared transactions | ||
+ | Checking for reg* data types in user tables | ||
+ | Checking for contrib/isn with bigint-passing mismatch | ||
+ | Checking for invalid " | ||
+ | Creating dump of global objects | ||
+ | Creating dump of database schemas | ||
+ | ok | ||
+ | Checking for presence of required libraries | ||
+ | Checking database user is the install user ok | ||
+ | Checking for prepared transactions | ||
+ | |||
+ | If pg_upgrade fails after this point, you must re-initdb the | ||
+ | new cluster before continuing. | ||
+ | |||
+ | Performing Upgrade | ||
+ | ------------------ | ||
+ | Analyzing all rows in the new cluster | ||
+ | Freezing all rows in the new cluster | ||
+ | Deleting files from new pg_xact | ||
+ | Copying old pg_clog to new server | ||
+ | Setting next transaction ID and epoch for new cluster | ||
+ | Deleting files from new pg_multixact/ | ||
+ | Copying old pg_multixact/ | ||
+ | Deleting files from new pg_multixact/ | ||
+ | Copying old pg_multixact/ | ||
+ | Setting next multixact ID and offset for new cluster | ||
+ | Resetting WAL archives | ||
+ | Setting frozenxid and minmxid counters in new cluster | ||
+ | Restoring global objects in the new cluster | ||
+ | Restoring database schemas in the new cluster | ||
+ | ok | ||
+ | Adding " | ||
+ | |||
+ | If you want to start the old cluster, you will need to remove | ||
+ | the " | ||
+ | Because " | ||
+ | started once the new cluster has been started. | ||
+ | |||
+ | Linking user relation files | ||
+ | ok | ||
+ | Setting next OID for new cluster | ||
+ | Sync data directory to disk ok | ||
+ | Creating script to analyze new cluster | ||
+ | Creating script to delete old cluster | ||
+ | Checking for hash indexes | ||
+ | |||
+ | Upgrade Complete | ||
+ | ---------------- | ||
+ | Optimizer statistics are not transferred by pg_upgrade so, | ||
+ | once you start the new server, consider running: | ||
+ | ./ | ||
+ | |||
+ | Running this script will delete the old cluster' | ||
+ | ./ | ||
+ | -bash-4.2$ | ||
+ | </ | ||
+ | |||
+ | |||
+ | ====Start the new Cluster==== | ||
+ | After that, we can delete the old cluster and start the one. | ||
+ | Please don't be afraid that the upgrade is via links, in that case links mean that both files point to the same piece of chunk in the hard disk. Meaning as long as we have one pointer (the new version) we can delete the old one (9.6). | ||
+ | These AREN'T SYMBOLIC links, these are hard links to the hard disk. | ||
+ | |||
+ | <sxh bash> | ||
+ | -bash-4.2$ cat delete_old_cluster.sh | ||
+ | #!/bin/sh | ||
+ | |||
+ | rm -rf '/ | ||
+ | -bash-4.2$ rm -rf '/ | ||
+ | -bash-4.2$ / | ||
+ | waiting for server to start....2020-01-20 10: | ||
+ | 2020-01-20 10: | ||
+ | 2020-01-20 10: | ||
+ | 2020-01-20 10: | ||
+ | 2020-01-20 10: | ||
+ | 2020-01-20 10: | ||
+ | done | ||
+ | server started | ||
+ | -bash-4.2$ psql | ||
+ | psql (10.11) <- Finally, upgraded to 10.11 | ||
+ | Type " | ||
+ | |||
+ | postgres=# | ||
+ | </ | ||
+ | |||
+ | ======Out-Of-Place====== | ||
+ | Out of place of place upgrade usually is done using one of the following: | ||
+ | |||
+ | * Complete installation of the new PostgreSQL on 2nd host and using pg_dumpall, pg_dump and psql to restore the data | ||
+ | * Using logical replication to minimize the downtime to almost 0. | ||
+ | |||
+ | |||
+ | We have two environments: | ||
+ | |||
+ | PostgreSQL 9.1 on Linux 5, which should be migrated to: | ||
+ | PostgreSQL 10 on Linux 7 | ||
+ | |||
+ | To migrate from such an old version there are two options | ||
+ | |||
+ | |||
+ | - Upgrade the current version to 10 and simply migrate the data using backup/ | ||
+ | - Backup the current version 9.1 using (pg_dumpall and pg_dump) and restore it (pg_restore) to the new version 10 | ||
+ | |||
+ | Since the first path will take waaay longer and since we are lazy AF, we will be using the second path | ||
+ | |||
+ | |||
+ | =====Backup===== | ||
+ | In order to backup the data in universal format we have to: | ||
+ | |||
+ | - Dump the globals: Roles & Tablespaces using pg_dumpall | ||
+ | - Dump each database (we will use the custom format " | ||
+ | |||
+ | So let's get going: | ||
+ | |||
+ | ===Dump Globals=== | ||
+ | <sxh bash> | ||
+ | |||
+ | |||
+ | |||
+ | </ | ||
+ |