数据库备份还原(上)
数据库备份
完全备份数据库:
#pg_dumpall > /backup-path/路径恢复指定数据库的数据
#/data/services/postgresql9/bin/psql -d databasename -f /backup-path/pg_dumpall可实现仅备份角色和表空间定义
pg_dumpall -h localhost -U postgres --port=5432 -f myglobals.sql --globals-only
如果仅需备份角色定义而无需备份表空间，那么可以加上--roles-only选项：
pg_dumpall -h localhost -U postgres --port=5432 -f myroles.sql --roles-only
pg_dumpall -h 10.154.5.219 -p 5432 -U postgres > myglobals.sql --globals-only备份数据库三种方法
SQL转储
文件系统级备份。
持续存档。
SQL转储
使用SQL命令生成一个文件。
备份用法: pg_dump dbname>dumpfile
pg_dump是一个常规的 PostgreSQL客户端应用程序.
pg_dump不能以特殊权限运行,必须具有对要备份的所有表的读访问权限.
pg_dump连接受普通客户端身份验证机制的约束。
pg_dump 不转储有关角色或表空间的信息。
恢复用法: psql dbname < dumpfile
在执行psql恢复之前,需要先创建数据库。
在还原SQL转储之前，所有拥有对象或被授予对转储数据库中对象的权限的用户必须已存在。
恢复时遇到SQL错误后, 退出恢复:
psql --set ON_ERROR_STOP=on dbname<dumpfile恢复备份后,在每个数据库上运行ANALYZE，以便查询优化器具有有用的统计信息。
ANALYZE分析
ANALYZE收集有关数据库中表的内容的统计信息:
select * from pg_statistic;
ANALYZE [ VERBOSE ] [ table_name [ ( column_name [, ...] ) ] ]
参数:
VERBOSE: 启用进度消息的显示。
table_name ： 要分析的特定表的名称。
column_name ： 要分析的特定列的名称。使用pg_dumpall
pg_dumpall备份给定集群中的每个数据库，还保留集群范围的数据，如角色和表空间定义。
用法:
pg_dumpall> dumpfile恢复:
psql -f dumpfilepostgres在恢复pg_dumpall转储时始终需要具有数据库超级用户访问权限，因为这需要恢复角色和表空间信息。
使用
pg_dumpall --globals-only选项单独转储群集范围的数据.
处理大型数据库
使用压缩转储:
pg_dump dbname| gzip> filename.gz恢复:
gunzip -c filename.gz | PSQLdbname
或者: cat filename.gz | gunzip | PSQLdbname使用
split: 制作1兆字节的块:pg_dump dbname| split -b 1m - filename使用
pg_dump的自定义转储格式:pg_dump -Fc dbname>filename自定义转储格式会在将数据写入输出文件时压缩数据.
自定义格式转储,必须使用
pg_restore进行恢复:pg_restore -d dbname filename使用pg_dump的并行转储功能:
使用-j参数控制并行度。并行转储仅支持“目录”归档格式。
pg_dump -j num-F d -fout.dir dbname
使用
pg_restore -j并行还原转储。这适用于“自定义”或“目录”归档模式的任何归档，无论是否已创建pg_dump -j.
文件系统级备份
直接复制PostgreSQL用于在数据库中存储数据的文件.
tar -cf backup.tar /services/install/postgresql10/data/必须关闭数据库服务器才能获得可用的备份,在恢复数据之前关闭服务器。
文件系统备份仅适用于整个数据库集群的完整备份和还原。
使用rsync 执行文件系统备份.需要关闭数据库服务。
文件系统备份通常比SQL转储大,进行文件系统备份可能会更快。
持续存档
连续存档和时间点恢复(PITR):
postgresql在数据目录中维护一个预写日志pg_wal。
日志记录对数据库的数据文件所做的每个更改。此日志主要用于崩溃安全目的：如果系统崩溃，可以通过"重放" 将数据库恢复到一致性 自上一个检查点以来所做的日志条目。
将文件系统级备份与WAL文件的备份相结合。
恢复时,先恢复文件系统备份，然后从备份的WAL文件重放以使系统进入当前状态。
优点:
不需要完全一致的文件系统备份。备份中的不一致都将通过日志重放进行更正。
只需继续存档WAL文件可实现连续备份。
可在任何时候停止重放,并拥有当时数据库的一致快照,支持时间点恢复.
注意
只支持恢复整个数据库集群。需要大量的归档存储,基本备份很大, 高可靠性的首选备份技术。
连续归档(在线备份) 需要连续的归档WAL文件。
设置WAL归档:
系统将此序列物理划分为WAL 段文件，通常为16MB.
段文件的数字名称反映了它们在抽象WAL序列中的位置.
启用WAL归档
将wal_level配置参数设置为replica
archive_mode设置为 on
并指定要在archive_command 配置参数中使用的shell命令。
这些设置在postgresql.conf文件中。
archive命令仅在已完成的WAL段上调用。
限制未归档数据的使用时间： 设置archive_timeout 以强制服务器至少经常切换到新的WAL段文件。archive_timeout一分钟左右的设置通常是合理的。
注意
WAL归档会恢复对PostgreSQL数据库中的数据所做的任何修改,但不会恢复对配置文件所做的更改。
wal_level只能在服务器启动时更改。archive_command可以使用配置文件重新加载来更改。
进行基本备份
使用
pg_basebackup工具. 备份可以是文件或者tar归档。full_page_writes禁用时,备份运行时性能下降。full_page_writes在备份模式期间有效地强制执行备份。使用备份
需要保留在文件系统备份期间和之后生成的所有WAL段文件
基本备份过程会创建一个备份历史记录文件，该文件立即存储在WAL归档区域中。此文件以文件系统备份所需的第一个WAL段文件命名。
使用低级API进行基本备份
低级基本备份可以以非独占或独占的方式进行。建议使用非独占方法。
非独占低级备份是允许其他并发备份运行的备份:
确保已启用WAL存档并正常工作。
作为具有运行pg_start_backup的权限的用户连接到服务器
SELECT pg_start_backup('label'，false，false);label 用来唯一标识此备份操作的任何字符串。
false 默认情况下,pg_start_backup时间比较长，因为执行检查点，并且检查点所需的I / O将在很长一段时间内展开，默认情况下是检查点间隔的一半.可以最大限度地减少对查询处理的影响.
false : 告诉pg_start_backup发起非排他性基础备份。
终止备份模式:
SELECT * FROM pg_stop_backup(false，true);
备份数据目录
pg_dynshmem/，pg_notify/，pg_serial/，pg_snapshots/，pg_stat_tmp/，和pg_subtrans/会在postmaster启动时进行初始化。
从备份中省略pg_wal/,postmaster.pid和postmaster.opts,pg_replslot,pg_dynshmem/，pg_notify/，pg_serial/，pg_snapshots/，pg_stat_tmp/，和pg_subtrans等目录。pgsql_tmp可以从备份中省略任何以文件或目录开头的文件或目录。
服务器停止时，无法使用pg_start_backup或pg_stop_backup。
独立热备份
archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)'
touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar zxf /var/lib/pgsql/backup.tar -C /var/lib/pgsql/archive/数据库还原
用全量备份恢复数据:
#su - postgres
$ psql -f postgres9.5-backup-2018-10-17.sql postgres