Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YXne6-0004UG-V7 for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2015 09:18:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YXne6-0007Po-8O for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2015 09:18:42 +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 1YXne4-0007Pf-NQ for pgsql-admin@postgresql.org; Tue, 17 Mar 2015 09:18:41 +0000 Received: from correo.teltronic.es ([93.92.233.233] helo=teltronic.es) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YXndz-0002me-FB for pgsql-admin@postgresql.org; Tue, 17 Mar 2015 09:18:37 +0000 Received: from RMELENDOW7 (unknown [192.168.8.40]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by correo.teltronic.es (Postfix) with ESMTP id 79B9C42821E; Tue, 17 Mar 2015 10:18:27 +0100 (CET) From: "Ruth Melendo" To: "'Craig Ringer'" Cc: "'pgsql-admin'" References: <001801d05fef$e8dca0a0$ba95e1e0$@teltronic.es> <005701d06081$c8acf450$5a06dcf0$@teltronic.es> In-Reply-To: Subject: Re: pgpool + BDR, is it possible? Date: Tue, 17 Mar 2015 10:18:38 +0100 Message-ID: <007801d06093$5abd0360$10370a20$@teltronic.es> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0079_01D0609B.BC82A3E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKit4q4wfTCuiNBr4Gl+K58GKyStAJgjQb9AWRyCJEBvy3o8JtPlG1w Content-Language: es X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org This is a multipart message in MIME format. ------=_NextPart_000_0079_01D0609B.BC82A3E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_007A_01D0609B.BC82A3E0" ------=_NextPart_001_007A_01D0609B.BC82A3E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your help. =20 My app is a GIS Server and we strongly need high availability. The = reason to be master/master is to share load because we have a lot of = users and as, this is an app for security sector, each node must be able = to work alone to ensure availability all the time.=20 =20 The 2 databases I want to configure for replica master/master are the = admin database which has no high amount of transactions and the = cartography one. The data db does not need replication because each node = has its own data cache coming from another control application. =20 With this description, do you still think that best way is = active/passive? I=C2=B4m not sure about that and it is taking me much = time to take a decision=E2=80=A6. :/ =20 Ruth Patricia Melendo Ventura Software Engineer TELTRONIC, S.A.U. T: +34 976 465656 Ext. 179 F: +34 976 465722=20 www.teltronic.es Logo40 =20 De: pgsql-admin-owner@postgresql.org = [mailto:pgsql-admin-owner@postgresql.org] En nombre de Craig Ringer Enviado el: martes, 17 de marzo de 2015 9:31 Para: Ruth Melendo CC: pgsql-admin Asunto: Re: [ADMIN] pgpool + BDR, is it possible? =20 (I've dropped the Cc of pgsql-general to avoid cross-posting) =20 On 17 March 2015 at 15:12, Ruth Melendo wrote: Ok, I will try to explain my environment. =20 I want to have a high availability environment in active/active mode. = [snip] Right, so that's some of the architecture, but nothing on the = application. You need to understand that you'd be working with asynchronous = replication here. The app has to be aware of and written to cope with = anomalies arising from that, like insert/insert conflicts, etc. BDR = provides some tools to help, like global sequences and user-defined = conflict handlers, but it's *not* the same thing as just pointing the = app at a standalone PostgreSQL server. The nodes are *not* always = consistent with each other (because it's asynchronous) so the app can = see older data on one node than on another. That sort of thing. If your goal is HA then I strongly recommend an active/passive setup = with failover. It will be simpler and not require app changes. BDR comes = into its own when you need latency tolerance, partition tolerance, etc, = and it doesn't sound like you do. =20 About Barman, to restore database =20 1.- Stop nodes=20 2.- Disable BDR in node 1 3.- Backup node 1 4.- Start node 1 5.- Delete data directory in node 2 6.- Start node 2 with BDR active. =20 That would be the recovery process? =20 Since there's no restore in that list, no, it wouldn't. I haven't = written step by step guidance there, but it's something that's worth = adding to the documentation, so I'll note that. ------=_NextPart_001_007A_01D0609B.BC82A3E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for your help.

 

My app is a GIS Server and we strongly need high availability. The = reason to be master/master is to share load because we have a lot of = users and as, this is an app for security sector, each node must be able = to work alone to ensure availability all the time. =

 

The 2 databases I want to configure for replica master/master are the = admin database which has no high amount of transactions and the = cartography one. The data db does not need replication because each node = has its own data cache coming from another control = application.

 

With this description, do you still think that best way is = active/passive? I=C2=B4m not sure about that and it is taking me much = time to take a decision=E2=80=A6. :/

 

Ruth Patricia = Melendo Ventura

Software Engineer

TELTRONIC, S.A.U.=

T: +34 976 465656=C2=A0=C2=A0 Ext. 179

F: +34 976 465722

www.teltronic.es

=

3DLogo40

 

De: = pgsql-admin-owner@postgresql.org = [mailto:pgsql-admin-owner@postgresql.org] En nombre de Craig = Ringer
Enviado el: martes, 17 de marzo de 2015 = 9:31
Para: Ruth Melendo
CC: = pgsql-admin
Asunto: Re: [ADMIN] pgpool + BDR, is it = possible?

 

(I've = dropped the Cc of pgsql-general to avoid = cross-posting)

 

On 17 = March 2015 at 15:12, Ruth Melendo <rmelendo@teltronic.es> = wrote:

Ok, I will try to explain my environment.

 

I want to have a high availability environment in active/active mode. = [snip]


Right, so that's some of the = architecture, but nothing on the = application.

You need to understand that you'd be = working with asynchronous replication here. The app has to be aware of = and written to cope with anomalies arising from that, like insert/insert = conflicts, etc. BDR provides some tools to help, like global sequences = and user-defined conflict handlers, but it's *not* the same thing as = just pointing the app at a standalone PostgreSQL server. The nodes are = *not* always consistent with each other (because it's asynchronous) so = the app can see older data on one node than on another. That sort of = thing.

If your goal is HA = then I strongly recommend an active/passive setup with failover. It will = be simpler and not require app changes. BDR comes into its own when you = need latency tolerance, partition tolerance, etc, and it doesn't sound = like you do.

 

About Barman, to restore database

 

1.- Stop nodes

2.- Disable BDR in node 1

3.- Backup node 1

4.- Start node 1

5.- Delete data directory in node 2

6.- Start node 2 with BDR active.

 

That would be the recovery = process?

 

Since there's no restore in that list, no, it = wouldn't. I haven't written step by step guidance there, but it's = something that's worth adding to the documentation, so I'll note = that.

------=_NextPart_001_007A_01D0609B.BC82A3E0-- ------=_NextPart_000_0079_01D0609B.BC82A3E0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAA0AD8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2as3W NdstEg8y6k+cj5I15Zvw/rVXxJ4hXRoVjgCy3knCR+g9T/h3qhonhYmb+0tcYzXbHcEc5VPr7+3Q VvCklHnqbfmc06zc/Z0tX1fRFC5vta121kvJLn+x9IUZ3Z/eOPboTnt0/GtTwHMW8LhpCwjWWTY8 jcsuc5Pp3/KsTV7mbxl4gTSLNtunwNukde+OC39B+dXfF+pCzt4tFsAFUoA4Uchf4VH1rqlBzSpJ Wb19F5+ZyKoqblWbulp6vy8iDxD41mkla00clcNtMwGS/so/rWSvh3xIxfUt7pNbjzA0kx3nvgf1 H4V1vhXwzHpUC3Vyub2ReQekY9B7+tXvE+oDTPD15OSA3llE92PA/nS9tGElTor59yvYSqRdWu/O 3Yd4c1Vta0K1vXXbJIuHA6bgcHH5VqVyXhWefR/DtjFc27eS671cdRuOf611MM8dwgeJwyn0rzZV qUqsqcXqm9D0acZ+yjKXVI8+tNVtIvEdzqGrJK0iufLRVDbSDjnnsBiruu+OYLnTZbbT45lklXaZ HAG0d+/pWxe+DdOvruS4Zp42kO5ljYAZ79q4zXdKtbDxFFp8Bk8rMYdpG5O488/Q168HRrST1ul8 tDxpRxGHi1pZvfq7kGg+IrnRQ1vp9nDLPcMBufJY+gABrd8MWj6z4hl1C6wfKbzG9N56Y+n+Fdja 6TYWQ/0W0hiONu5EAbH161yGl6onhK7vrS+gmO5wyFAOQM4644qfaqqp+zj7xU6Loyp+1l7qb9F2 O6JCqSxwBySa871S9PjXxNa6fa7jYQtlmxjcP4m/LgVHquv6l4omFjYQOkJP+rQ5LD1Y+ldh4b8O xaBaMu4SXEpBkkxj8B7CsVBYZc0vi6LsdLqfWpcsPhW77+RqG3iNuINi+UFChewHasCCZtOvZFU5 VSVI9fStW/1SO1BSMiSY8BR2+tVtM01y/wBouRyckKe+e5r5vG3r14Ro/Et329f8j2aPuQbnszYr Km8P6fPrH9ozx+ZcALgM3yjHQ4rVrHEM7XbRkhnJLueoP93P9BXsxk47M45QjL4lc0HuJFkZVh3k dlcZx64NZt/Fb6suLnTPPEZ27jKgKn0yDU0VrcNbrvjxITh8vy4+o7Z59TQtjK9pIjxJuDkoucA9 vw46VnaSd4ya+7/IpqMlaSuRW0MmnQrHYafbWqM2Pnk5Y/hnP51YNle3GRc3gVD/AAwrjP4mg2cz TIjRxiGMqyEN93HbFaNZyo87vOTfz/ysVGXKrRSRVtdNtrQ5ij+b+83Jq1RRVwhGC5YqyE5OTuwp oRVLEAAsck+tFFWIdRRRQAUUUUAFFFFAH//Z ------=_NextPart_000_0079_01D0609B.BC82A3E0--