1、在繁忙的系统中，如果需要降低checkpoint发生的频率，减少WAL日志的生成量，减轻对系统IO的压力，可以通过以下两种方法。
1) 调整WAL segment大小，最高可以调整到64MB，不过只能通过编译来调整。对于已有系统不太方便；
2) 增大checkpoint_segments设置，使得checkpoint不会过于频繁地被触发；
2、在9.5中，checkpoint_segments被废弃，可以通过新增参数max_wal_size来调整，该参数缺省为1GB，已经是9.4的2倍。但如果9.4中手工设置了checkpoint_segments，如本例，则以下的公式可以做为9.5设置max_wal_size的参考。
max_wal_size = (3 * checkpoint_segments) * 16MB
补充：PostgreSQL利用全备与WAL日志恢复数据库
一般情况全备只能做到备份时刻的恢复，在全备操作过后的数据库信息无法同步，此时就需要利用wal日志来进行时间点的恢复
基础备份——全备
使用pg_basebackup
pg_basebackup是postgresql提供的一个方便基础备份的工具（9.1开始提供），这个工具会把整个数据库实例的数据都拷贝出来，而不只是把实例中的部分（如某个数据库或表）单独备份出来，该工具使用replication协议连接到数据库实例上，所以主数据库中的pg_hba.conf必须允许replication连接，类似如下：
local replication postgre ident
在9.2之后支持级连复制，所以在之后的版本中，pg_basebackup也可以从另外一个standby库上做基础备份，都需注意如下几方面：
1、备份中没有备份历史文件；
2、不确保所有需要的WAL文件都备份了，如果想确保，需要加命令行参数 ”-x";
3、如果在备份过程中standby被提升为主库，则备份会失败；
4、要求主库中打开了“full_page_writes"参数，WAL文件不能被类似pg_compresslog的工具去掉full_page_writes信息。
参数
-Ft F表示输出格式，t为tar包的格示，p，默认值，输出为目录。
-X fetch X表示收集wal日志的方式 fetch表示收集wal日志，stream为不收集，以备库streaming的方式追赶主库，none一般不使用
-h 要备份数据库的所在的IP
-p 数据库端口号
-P 备份进度，以百分制显示
-v 输出备份信息，如上面pg_basebackup:等类似语句。
-W 输入密码选项
-D 要备份到的目录
其他选项 比如-R 备份备库时保存recover.conf文件
WAL日志的的备份
测试流程
将被数据文件全备
一台是已运行的主库，一台是安装好数据库但是没有初始化的预恢复库
将主库的数据文件全备到备库的的数据目录中
继续操作主库
在表中插入几行数据，并留下时间
postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1 postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1 postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1 postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1 postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1 postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1
postgres=# select now(); now ------------------------------- 2018-07-18 15:03:28.969495+08 (1 row) postgres=#
切换wal日志
postgres=# select pg_switch_wal(); pg_switch_wal --------------- 5/EF0009D8 (1 row) postgres=#
####将wal日志归档到备库
这边是直接将日志传过去，到备库的/backup 目录
配置recovery.conf文件
在pgdata目录里，创建文件
[postgres@mdw pgdata]$ cat recovery.conf recovery_target_time = ' 2018-07-18 11:00:18.526347+08 ' restore_command = 'cp /backup/pg_wal/%f %p'
启动恢复实例
[postgres@mdw pgdata]$ pg_ctl start waiting for server to start....2018-07-18 15:07:52.420 CST [3353] LOG: listening on IPv4 address "0.0.0.0", port 5432 2018-07-18 15:07:52.420 CST [3353] LOG: listening on IPv6 address "::", port 5432 2018-07-18 15:07:52.426 CST [3353] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432" 2018-07-18 15:07:52.468 CST [3354] LOG: database system was interrupted; last known up at 2018-07-18 15:00:09 CST 2018-07-18 15:07:52.950 CST [3354] LOG: starting point-in-time recovery to 2018-07-18 15:03:28.969495+08 2018-07-18 15:07:52.987 CST [3354] LOG: restored log file "0000000100000005000000F8" from archive 2018-07-18 15:07:53.247 CST [3354] LOG: redo starts at 5/F8000028 2018-07-18 15:07:53.308 CST [3354] LOG: consistent recovery state reached at 5/F8000B08 2018-07-18 15:07:53.308 CST [3353] LOG: database system is ready to accept read only connections done server started [postgres@mdw pgdata]$ 2018-07-18 15:07:53.343 CST [3354] LOG: restored log file "0000000100000005000000F9" from archive 2018-07-18 15:07:53.626 CST [3354] LOG: restored log file "0000000100000005000000FA" from archive 2018-07-18 15:07:54.192 CST [3354] LOG: invalid record length at 5/FA000140: wanted 24, got 0 2018-07-18 15:07:54.192 CST [3354] LOG: redo done at 5/FA000108 2018-07-18 15:07:54.192 CST [3354] LOG: last completed transaction was at log time 2018-07-18 15:03:20.200594+08 2018-07-18 15:07:54.397 CST [3354] LOG: restored log file "0000000100000005000000FA" from archive cp: cannot stat `/backup/pg_wal/00000002.history': No such file or directory 2018-07-18 15:07:54.633 CST [3354] LOG: selected new timeline ID: 2 cp: cannot stat `/backup/pg_wal/00000001.history': No such file or directory 2018-07-18 15:07:55.160 CST [3354] LOG: archive recovery complete 2018-07-18 15:07:55.263 CST [3353] LOG: database system is ready to accept connections
查看恢复情况
发现已经将之后的操作在备库上进行恢复了
postgres=# select * from test08 where id=6666666; id | n ---------+------- 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg (6 rows)
以上为个人经验，希望能给大家一个参考，也希望大家多多支持。如有错误或未考虑完全的地方，望不吝赐教。
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！ 如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。