← Back to branch summary

~thomir-deactivatedaccount/charms/trusty/postgresql/fix-for-lxc

« back to all changes in this revision

Viewing changes to README.md

  • Committer: Tim Van Steenburgh
  • Date: 2014-11-19 15:36:53 UTC
  • mfrom: (105.1.1 docs)
  • Revision ID: tim.van.steenburgh@canonical.com-20141119153653-h4xe2wxx86mpi9g5
[stub] Document permissions best practice

Show diffs side-by-side

added added

removed removed

Lines of Context:
README.md
100
100
automatically generated user for `db-admin` relations is a PostgreSQL
101
101
superuser.
102
102
 
 
103
## Database Permissions and Disaster Recovery
 
104
 
 
105
⚠ These two topics are entwined, because failing to follow best
 
106
  practice with your database permissions will make your life difficult
 
107
  when you need to recover after failure.
 
108
 
 
109
_Always_ set the 'roles' relationship setting when joining a
 
110
relationship. _Always_ grant permissions to database roles for _all_
 
111
database objects your charm creates. _Never_ rely on access permissions
 
112
given directly to a user, either explicitly or implicitly (such as being
 
113
the user who created a table). Consider the users you are provided by
 
114
the PostgreSQL charm as ephemeral. Any rights granted directly to them
 
115
will be lost if relations are recreated, as the generated usernames will
 
116
be different. _If you don't follow this advice, you will need to
 
117
manually repair permissions on all your database objects after any of
 
118
the available recovery mechanisms._
 
119
 
 
120
Learn about the SQL `GRANT` statement in the excellect [PostgreSQL
 
121
reference guide][3].
 
122
 
 
123
### block-storage-broker
 
124
 
 
125
If you are using external storage provided by the block storage broker,
 
126
recovery or a failed unit is simply a matter of ensuring the old unit
 
127
is fully shut down, and then bringing up a fresh unit with the old
 
128
external storage mounted. The charm will see the old database there
 
129
and use it.
 
130
 
 
131
If you are unable or do not wish to to simply remount the same
 
132
filesystem, you can of course copy all the data from the old filesystem
 
133
to the new one before bringing up the new unit.
 
134
 
 
135
### dump/restore
 
136
 
 
137
PostgreSQL dumps, such as those that can be scheduled in the charm, can
 
138
be recovered on a new unit by using 'juju ssh' to connect to the new unit
 
139
and using the standard PostgreSQL `pg_restore(1)` tool. This new unit must
 
140
be standalone, or the master unit. Any hot standbys will replicate the
 
141
recovered data from the master.
 
142
 
 
143
You will need to use `pg_restore(1)` with the `--no-owner` option, as
 
144
users that existed in the old service will not exist in the new
 
145
service.
 
146
 
 
147
### PITR
 
148
 
 
149
If you had configured WAL-E, you can recover a WAL-E backup and replay
 
150
to a point in time of your choosing using the `wal-e` tool. This
 
151
will recover the whole database cluster, so all databases will be
 
152
replaced.
 
153
 
 
154
If there are any hot standby units, they will need to be destroyed
 
155
and recreated after the PITR recovery.
 
156
 
 
157
 
103
158
## During db-relation-joined
104
159
 
105
160
### the client service provides:
304
359
 
305
360
  [1]: https://bugs.launchpad.net/charms/+source/postgresql/+bug/1258485
306
361
  [2]: https://github.com/wal-e/wal-e
 
362
  [3]: http://www.postgresql.org/docs/9.3/static/sql-grant.html