I would like to switch from postgres 9.6 to version 14 which runs on Ubuntu 21.04. I have a cluster with 3 databases.
I would like to know what is the difference between upgrading with pg_upgrade and pg_upgradecluster? Which one is faster and safer?
pg_upgrade is a tool from Postgresql itself that will operate on a single database (folder).
pg_upgradecluster however is a wrapper from your operating system (= Ubuntu) to pg_upgrade or pg_dump/pg_restore. In addition to very conveniently upgrading your database, it will also do some housekeeping like moving the config files to the correct folder in /etc/postgres/ .
So, if you have set up your database by pg_createcluster and it is hence listed by pg_lsclusters, I'd strongly recommend using pg_upgradecluster to upgrade it.
In terms of "faster vs. safer", be sure to read about the various options on the manpage.
If you can take a reliable backup (e.g. snapshot), you can safely use the -m upgrade --link option which will be fastest and allow for a very short downtime (depending on database size and resources, but I've recently upgraded a 700GB database in ~25 seconds).
The safest option of course is not using pg_upgrade, but the default pg_dump/pg_restore method, which will shut down your original database and copy the data to a new database in a new location (= it will use at approx. twice the space, at least temporarily until you decide to delete the original folder).
Related
I have postgres 9.5 database with one master and two replicas. My project is on c++.
To check if master instance is available I run mock query. Is there more convenient way to do this?
UPD: I know about instruments which can be used in terminal such as systemctl and pg_isready, but they are not applicable to use from c++ project
We use repmgr to keep an eye on all clusters and to manage the primary and secondary databases.
But version 9.5, are you sure? That's EOL for a pretty long time. Plan a move to version 14.
I am trying upgrade postgres-9.3 to postgres-10 with database size around 165GB. I am using "sudo pg_upgradecluster 9.3 main" to do so but it's taking around 8hours which is way too much downtime for my live webapp. Any suggestions to make it better with lesser downtime and faster.
You can tell pg_upgradecluster to use Postgres' pg_upgrade tool with the --link option which should then finish in minutes rather than hours:
pg_upgradecluster --method=upgrade --link ......
Note that --link will not copy your data, so the only way to revert the upgrade is to restore your last backup to a 9.3 installation.
Quote from the Postgres manual
If you use link mode, the upgrade will be much faster (no file copying) and use less disk space, but you will not be able to access your old cluster once you start the new cluster after the upgrade.
...
If you want to use link mode and you do not want your old cluster to be modified when the new cluster is started, make a copy of the old cluster and upgrade that in link mode. To make a valid copy of the old cluster, use rsync to create a dirty copy of the old cluster while the server is running, then shut down the old server and run rsync --checksum again to update the copy with any changes to make it consistent.
I have a Postgresql 10 installation on Ubuntu 18.04 that somehow broke and won't restart. Can I just reinstall it without destroying its databases, so that I can access the databases again? pg_dump doesn't work.
Yes, you can do that.
By default, your databases and other important files are stored in PGDATA.
Traditionally, the configuration and data files used by a database cluster are stored together within the cluster's data directory, commonly referred to as PGDATA (after the name of the environment variable that can be used to define it). A common location for PGDATA is /var/lib/pgsql/data.
https://www.postgresql.org/docs/10/storage-file-layout.html
I don't know how you will uninstall PostgreSQL, but be sure to keep PGDATA.
(yum or apt won't delete PGDATA)
After re-installing PostgreSQL, make sure to launch your PostgreSQL with your existing PGDATA
pg_ctl start -D YOUR_EXISTING_PGDATA/
A linux VM with postgres 9.4 was hacked into. (Two processes taking 100% cpu, weird files in /tmp, did not reoccur after kill(s) and restart.) It was decided to install the system from scratch on a new machine (with postgres 9.6). The only data needed was in one of postgres databases. A pg_dump of the database was made after the attack.
Regardless of whether the data - the tables/rows/etc. - were modified during the attack: is it safe to restore the database in the new system?
I consider using pg_restore with the -O option (ignores the user permissions)
The two dangers are:
important data could have been modified
back doors could have been installed in your database
With the first, you're on your own how to verify that your data are ok. The safest thing would be to use a backup from before the machine was compromized, but this would mean data loss.
For the second, I would run a pg_dumpall -s and spend a day reading it carefully. Compare it with a dump from a backup made before the breach. Watch out for weird object and column names and functions with SECURITY DEFINER.
I was working with postgresql, and suddenly, this stop it. I stoped service, but when i try start it, never i can do it.
service postgresql start FAIL
don't have a backup, and with pg_dump is imposible.
pg_dump -i -h localhost -p 5432 -U postgres -F c -b -v -f "/mibase.backup" mydatabase
which is the best form to do a backup?
I had a lot of trouble with PostgreSQL 9.0.2 under Windows. The service would just stop every couple of days. I never had trouble restarting it, though. Never had to restart the Windows server to restart the PostgreSQL service.
With the PostgreSQL service shut down, you can copy the database files.
If you're not on the most current release of your version, you might try installing a more recent minor version. Postgresql doesn't mind running multiple versions on the same server, although they each have to listen on a different port.
The minor version number is the third digit. Above, the major version is "9.0". If you're running 9.0.2, you want 9.0.[a number greater than 2]. Why?
"Minor releases never change the internal storage format and are always compatible with earlier and later minor releases of the same major version number, e.g., 8.4.2 is compatible with 8.4, 8.4.1 and 8.4.6." (Upgrading a PostgreSQL Cluster)
So a minor version upgrade, listening on a different port, and pointing to your old data directory might let you make a SQL dump. A SQL dump can be restored to any version.
A minor version upgrade pointing to a new data directory should be able to read files copied at the filesystem level. (Paragraph 2, way above.)