Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Y0nQp-0007b6-QO for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Dec 2014 08:24:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Y0nQp-0004ue-8t for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Dec 2014 08:24:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Y0nQm-0004rG-PK for pgsql-hackers@postgreSQL.org; Tue, 16 Dec 2014 08:24:32 +0000 Received: from forward1l.mail.yandex.net ([84.201.143.144]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Y0nQi-000518-K6 for pgsql-hackers@postgreSQL.org; Tue, 16 Dec 2014 08:24:30 +0000 Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 96B7715217CA; Tue, 16 Dec 2014 11:24:23 +0300 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 1E59316A176C; Tue, 16 Dec 2014 11:24:23 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:108:1182:6b55:5e70:a32b]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id IzdhD21ZmP-OLj4VtoB; Tue, 16 Dec 2014 11:24:22 +0300 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simply.name; s=mail; t=1418718262; bh=PjYEGSLvxJr9OwgP2rrJKteGrGB6AsYp+M2HKlJcbok=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To:X-Mailer; b=UJBaKvaHYAqLyM0g49t+43ZFV/2NxNS7NyKYiXtoRUQslkQesTPEFy0Pxm3DPvxs5 Ay/K13ENevfeR+6EfQCMyk3ZoGaF+yyrJjMXLLTUBODE6W5j1TX7+ttV4cH4uPMnDj 7xpGktFtt4a/IQCMF6NRQhsYJpOVH2zaUhW5SZEo= Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@simply.name Content-Type: multipart/alternative; boundary="Apple-Mail=_7C057A73-972A-483F-A8A4-68EB7AC431DF" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Streaming replication and WAL archive interactions From: Borodin Vladimir In-Reply-To: <548AF1CB.80702@vmware.com> Date: Tue, 16 Dec 2014 11:24:22 +0300 Cc: PostgreSQL-development Message-Id: <689EB259-44C2-4820-B901-4F6B1C55A1E4@simply.name> References: <548AF1CB.80702@vmware.com> To: Heikki Linnakangas X-Mailer: Apple Mail (2.1878.6) X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org --Apple-Mail=_7C057A73-972A-483F-A8A4-68EB7AC431DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1251 12 =E4=E5=EA. 2014 =E3., =E2 16:46, Heikki Linnakangas = =ED=E0=EF=E8=F1=E0=EB(=E0): > There have been a few threads on the behavior of WAL archiving, after = a standby server is promoted [1] [2]. In short, it doesn't work as you = might expect. The standby will start archiving after it's promoted, but = it will not archive files that were replicated from the old master via = streaming replication. If those files were not already archived in the = master before the promotion, they are not archived at all. That's not = good if you wanted to restore from a base backup + the WAL archive = later. >=20 > The basic setup is a master server, a standby, a WAL archive that's = shared by both, and streaming replication between the master and = standby. This should be a very common setup in the field, so how are = people doing it in practice? Just live with the wisk that you might miss = some files in the archive if you promote? Don't even realize there's a = problem? Something else? Yes, I do live like that (with streaming replication and shared archive = between master and replicas) and don=92t even realize there=92s a = problem :( And I think I=92m not the only one. Maybe at least a note = should be added to the documentation? >=20 > And how would we like it to work? >=20 > There was some discussion in August on enabling WAL archiving in the = standby, always [3]. That's a related idea, but it assumes that you have = a separate archive in the master and the standby. The problem at = promotion happens when you have a shared archive between the master and = standby. AFAIK most people use the scheme with shared archive. >=20 > [1] = http://www.postgresql.org/message-id/CAHGQGwHVYqbX=3DA+zo+AvFbVHLGoypO9G_Q= DKbabeXgXBVGd05g@mail.gmail.com >=20 > [2] http://www.postgresql.org/message-id/20140904175036.310c6466@erg >=20 > [3] = http://www.postgresql.org/message-id/CAHGQGwHNMs-syU=3DMEVSESTHna+Exd9pfO_= OHHFPJCwOVaYRZKw@mail.gmail.com. >=20 > - Heikki >=20 >=20 > --=20 > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Vladimir --Apple-Mail=_7C057A73-972A-483F-A8A4-68EB7AC431DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1251
12 =E4=E5=EA. 2014 =E3., =E2 16:46, = Heikki Linnakangas <hlinnakangas@vmware.com> = =ED=E0=EF=E8=F1=E0=EB(=E0):

There have = been a few threads on the behavior of WAL archiving, after a standby = server is promoted [1] [2]. In short, it doesn't work as you might = expect. The standby will start archiving after it's promoted, but it = will not archive files that were replicated from the old master via = streaming replication. If those files were not already archived in the = master before the promotion, they are not archived at all. That's not = good if you wanted to restore from a base backup + the WAL archive = later.

The basic setup is a master server, a standby, a WAL = archive that's shared by both, and streaming replication between the = master and standby. This should be a very common setup in the field, so = how are people doing it in practice? Just live with the wisk that you = might miss some files in the archive if you promote? Don't even realize = there's a problem? Something = else?

Yes, I do live like that (with = streaming replication and shared archive between master and replicas) = and don=92t even realize there=92s a problem :( And I think I=92m not = the only one. Maybe at least a note should be added to the = documentation?


And how would we = like it to work?

There was some discussion in August on enabling = WAL archiving in the standby, always [3]. That's a related idea, but it = assumes that you have a separate archive in the master and the standby. = The problem at promotion happens when you have a shared archive between = the master and standby.

AFAIK most = people use the scheme with shared archive.


[1] http://www.postgresql.org/message= -id/CAHGQGwHVYqbX=3DA+zo+AvFbVHLGoypO9G_QDKbabeXgXBVGd05g@mail.gmail.com

[2] = http://www.postgresql.org/message-id/20140904175036.310c6466@erg
[3] http://www.postgresql.org/message= -id/CAHGQGwHNMs-syU=3DMEVSESTHna+Exd9pfO_OHHFPJCwOVaYRZKw@mail.gmail.com.

- Heikki


--
Sent via pgsql-hackers mailing = list (pgsql-hackers@postgresql.org<= /a>)
To make changes to your subscription:
http://www.postg= resql.org/mailpref/pgsql-hackers

--
Vladimir




= --Apple-Mail=_7C057A73-972A-483F-A8A4-68EB7AC431DF--