|Summary||Deploy a PostgreSQL database with hot standby replica.|
|Author||Tim McNamara email@example.com|
Running your own database might sound like a silly thing to do these days. There are many hosted databases in the cloud. But, self-hosting is significantly cheaper. And it’s also probably easier than you think.
If you are new to Juju, consider our Get started Tutorials.
$ juju deploy postgresql -n 2 --storage="pgdata=500G" --constraints="cores=4 mem=8G" Located charm "cs:postgresql-203". Deploying charm "cs:postgresql-203".
The storage options and constraints provided to the
juju deploy command are all that Juju needs to identify the correct instance.
-n 2asks for 2 “units” of the
postgresqlcharm to be deployed. When multiple units are deployed, PostgreSQL will be deployed with a failover secondary node.
--storagerequests that the cloud provider allocate storage that is not destroyed when instances are torn down. The
pgdatalabel is defined by the charm.
--constraints="cores=4 mem=8G"tells Juju to request instances from the cloud provider with at least 4 CPU cores and 8GB RAM each.
A constraint is a minimum requirement placed on Juju when it selects which instances to provision from the cloud provider.
Several application constraints are available. The most commonly used are
Feel free to customise the application’s constraints. If you have low demands, then specify less memory than 8GB in the
postgresql charm has several configuration options. View them all via the
juju config command:
$ juju config postgresql
Useful options to consider are
admin_addressesto whitelist IP addresses that administrative tools such as pgAdmin can connect from
backup_scheduleto ensure that
pg_dumpbackups are performed with sufficient frequency, and
extra_pg_confto tune the database server.
(Optional) Expose PostgreSQL to the Internet
$ juju expose postgresql
Note: Applications deployed with Juju within this model do not actually require PostgreSQL to be exposed to the Internet.