Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjhar-00088s-H9 for pgsql-zh-general@arkaria.postgresql.org; Tue, 13 Sep 2016 06:53:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bjhaq-00078u-JX for pgsql-zh-general@arkaria.postgresql.org; Tue, 13 Sep 2016 06:53:20 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bjhai-00070l-Ur for pgsql-zh-general@postgresql.org; Tue, 13 Sep 2016 06:53:13 +0000 Received: from m97135.qiye.163.com ([220.181.97.135]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjhaa-00032I-W6 for pgsql-zh-general@postgresql.org; Tue, 13 Sep 2016 06:53:08 +0000 Received: from localhost.localdomain (unknown [124.127.160.226]) by smtp1 (Coremail) with SMTP id h+CowACHi81KotdXgBGKAw--.42913S2; Tue, 13 Sep 2016 14:52:59 +0800 (CST) To: "pgsql-zh-general@postgresql.org" From: Quan Zongliang Subject: =?UTF-8?Q?Postgres_10_highlight_-_recovery=5ftarget=5flsn=ef=bc=88?= =?UTF-8?B?5a6Y5pa55Y2a5a6i57+76K+R77yJ?= Message-ID: Date: Tue, 13 Sep 2016 14:52:58 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: h+CowACHi81KotdXgBGKAw--.42913S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxZFWDuF13AF48ZF18Zw17Awb_yoW5Gw1Upr n3Jry3KFW7tFWkKrs2qw1UArW3Kw47GF47JryUGw4xtr4avrn8X34rKF4kXryYvrZFgan2 gaykA34UCr4q9aUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jjVbkUUUUU= X-Originating-IP: [124.127.160.226] X-CM-SenderInfo: p2rqwzpldqwhhtxd0qxsrv3wxuhvvt1wdou0bp/1tbiQwzjGlbdGjYXywAAsN X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-zh-general Precedence: bulk Sender: pgsql-zh-general-owner@postgresql.org 原文链接: http://paquier.xyz/postgresql-2/postgres-10-recovery-target-lsn/ 翻译水平有限,如有疑问以原文为准。 PITR时,PG提供几种估算停止点的方法来停止恢复(WAL重演): recovery_target_time指定时间戳 recovery_target_name指定名字(用户使用函数pg_create_restore_point()定义的恢复目标) recovery_target_xid指定XID,恢复到指定事务ID提交的时刻 recovery_target = ‘immediate’ 指定恢复到服务器能够到达的一致性状态 recovery_target_inclusive也可以影响恢复点设置,默认为true。(恢复参数列表见 这里) 今天的文章是关于新的恢复点类型,由下边的提交引入到PostgreSQL 10: commit: 35250b6ad7a8ece5cfe54c0316c180df19f36c13 author: Simon Riggs date: Sat, 3 Sep 2016 17:48:01 +0100 New recovery target recovery_target_lsn Michael Paquie LSN是WAL流的位置(也可以成为WAL日志偏移量offset),简单说就是一组知道记录在哪里插入的位置定义,比如“0/7000290”,使用这个参数可以指定记录级恢复。在很多案例中这非常有用,最常见的例子是WAL损坏而用户想尽可能多的恢复数据,不需要深度分析WAL段去查找设置哪一个事务ID或者时间,只需要把它设置到某一记录就好。甚至可以利用像pg_current_xlog_location()这样常规的SQL,找到正在运行的服务器的当前LSN位置。 下边用一个做过基础备份(能够向前重演)的数据库作为例子演示: =# CREATE TABLE data_to_recover(id int); CREATE TABLE =# INSERT INTO data_to_recover VALUES (generate_series(1, 100)); INSERT 0 100 =# SELECT pg_current_xlog_location(); pg_current_xlog_location -------------------------- 0/3019838 (1 row) 插入到数据库中的数据使用WAL到位置“0/3019838”(原文 0/152F080怀疑有误),继续插入更多数据: =# INSERT INTO data_to_recover VALUES (generate_series(101, 200)); INSERT 0 100 =# SELECT pg_current_xlog_location(); pg_current_xlog_location -------------------------- 0/301B1B0 (1 row) 后来插入的数据消耗了一些(WAL)记录,现在我们用包含下边内容的recovery.conf恢复到前100条记录的插入状态(确定最后的WAL段已经归档)。 recovery_target_lsn = '0/3019838' restore_command = 'cp /path/to/archive/%f %p' PITR完成以后,会提示类似下边内容的日志(然后恢复暂停) LOG: recovery stopping after WAL position (LSN) "0/3019838" 登录到这个结点,只有100条数据: =# SELECT count(*) FROM data_to_recover; count ------- 100 (1 row) 对我个人而言,它是个强大的工具。 翻译结束 -- 权宗亮 神州飞象(北京)数据科技有限公司 我们的力量源自最先进的开源数据库PostgreSQL zongliang.quan@postgresdata.com -- Sent via pgsql-zh-general mailing list (pgsql-zh-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-zh-general