|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.103 2007/09/29 01:36:10 tgl Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.104 2007/10/16 02:48:57 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="backup"> |
4 | 4 | <title>Backup and Restore</title> |
@@ -1740,6 +1740,16 @@ pg_dumpall -p 5432 | psql -d postgres -p 6543 |
1740 | 1740 | access. |
1741 | 1741 | </para> |
1742 | 1742 |
|
| 1743 | + <para> |
| 1744 | + It is also possible to use <productname>Slony</> to create a slave |
| 1745 | + server with the updated version of <productname>PostgreSQL</>. The |
| 1746 | + slave can be on the same computer or a different computer. Once it |
| 1747 | + has synced up with the master server (running the older version of |
| 1748 | + <productname>PostgreSQL</>), you can switch masters and make the slave |
| 1749 | + the master and shut down the older database instance. Such a |
| 1750 | + switch-over results in only several minutes of downtime for an upgrade. |
| 1751 | + </para> |
| 1752 | + |
1743 | 1753 | <para> |
1744 | 1754 | In practice you probably want to test your client |
1745 | 1755 | applications on the new setup before switching over completely. |
|