[Bucardo-general] Problem with bytea on 4.5.0 and Postgres 9

[Gustavo Tonini]

Hello,
I'm experiencing a data corruption in bytea fields using swap syncs.

I made an update on DB A setting the value to \x373737. After replicate, DB
B shows value \x78333733373337.

Changing the parameter bytea_output to espace seems to work, but to change
my application should be hard.

How can I fix this? The problem didn't happen in Postgres 8.4.


Gustavo.
___
Bucardo-general mailing list
Bucardo-general@bucardo.org
https://mail.endcrypt.com/mailman/listinfo/bucardo-general

Re: [Bucardo-general] Syncing a third master into the cluster

[Gustavo Tonini]

Pedro,
Simply register the new node, add it in your sync creating a row on dbmap
table and restart bucardo. Validate sync will do all the magic.

I dont know if it is the official method but I have used it for years and
never had problems.

Gustavo.

Em ter, 26 de jan de 2016 15:57, Pedro França 
escreveu:

> Hello guys! I'm testing Bucardo for a multi-master environment and its
> been working really well with two nodes so far. They have both started with
> the same data and are still synced as inserts are happening on both nodes.
> Nice!
>
> But I wanted to know what is the best way to add a third node on the
> cluster with only a schema dump to start and if there is a way to do that
> with other two still accepting connection and wrriting.
>
> Sorry if that type of question is too simple but I couldn't find it
> anywhere.
>
> Thank you in advance.
> Pedro Ivo
>
>
>
>
> ___
> Bucardo-general mailing list
> Bucardo-general@bucardo.org
> https://mail.endcrypt.com/mailman/listinfo/bucardo-general
>
___
Bucardo-general mailing list
Bucardo-general@bucardo.org
https://mail.endcrypt.com/mailman/listinfo/bucardo-general

[Bucardo-general] Txntime should be commit time

[Gustavo Tonini]

Hey guys,
I have an environment where the current implementation of txntime (set to
transaction start time) is causing problems. It has long transactions so
the conflict resolution strategy (latest) sometimes overwrites the real
latest value (which belongs to the most recently committed transaction but
which has unfortunatelly started a long time ago).

Supposing an accurate clock in all servers, a txntime set to transaction
commit time should solve this issue.

Do you see any workaround or another strategy to avoid this problem?

Gustavo.
___
Bucardo-general mailing list
Bucardo-general@bucardo.org
https://mail.endcrypt.com/mailman/listinfo/bucardo-general

Re: [Bucardo-general] From PG 9.2 to 12.4 - Bucardo questions

[Gustavo Tonini]

Lucas,
if the parameter works in RDS, you can perfectly have a multimaster setup
and write to any DB that belongs to the sync. The data will be replicated
to the other nodes of the sync.

*session_replication_role* is a session parameter that is only set by
bucardo when it copies the modified data among the nodes so bucardo delta
triggers are not activated creating an infinite loop of data replication.
Your application will run with *session_replication_role*=false, so when it
changes something, bucardo triggers will be activated marking the rows to
be replicated in delta tables and notifying bucardo server to replicate the
changes.

Gustavo.

On Mon, Mar 8, 2021 at 11:33 PM Lucas Possamai  wrote:

> Gustavo, I did not find that information about the
>> *session_replication_role* online. Where is that on Bucardo's website?
>>
>> Lucas
>>
>
> Okay.. looking at that parameter better, it is safer to activate that than
> disabling triggers. It is possible to activate that parameter on RDS as
> well. Looks like Bucardo needs to update their documentation.
>
> However, I still do not know if I can have a multi-master setup, but at
> the same time, having an application pointed to the target_db writing data.
> Probably not since *session_replication_role* will be enabled.
>
> Lucas
>


-- 
Gustavo.
___
Bucardo-general mailing list
Bucardo-general@bucardo.org
https://bucardo.org/mailman/listinfo/bucardo-general

Re: [Bucardo-general] From PG 9.2 to 12.4 - Bucardo questions

[Gustavo Tonini]

Lucas,
In order to work properly, Bucardo needs to set the parameter
"session_replication_role" (which disables triggers, FKs and checks) for
each node in the replication session.

I think this is not possible in a managed RDS instance.

Gustavo.

On Mon, Mar 8, 2021, 22:05 Lucas Possamai  wrote:

> On Mon, 8 Mar 2021 at 19:42, Lucas Possamai  wrote:
>
>> Hi all.
>>
>> I am migrating a live PostgreSQL 9.2 database to RDS PostgreSQL 12.4,
>> using Bucardo.
>>
>> I remember reading somewhere months ago that I should disable the
>> triggers of the target database, but unfortunately, I cannot find that
>> information anymore.
>>
>> The business wants to slowly move customers to the PG 12.4 RDS database.
>> The idea was to modify the application and check if it's *customer_id X,
>> Y and Z*, write data to RDS and not current PG 9.2.
>>
>> My question is:
>> Can I have bucardo replicating data from PG 9.2 to RDS 12.4 and at the
>> same time, have customers writing data to RDS? Of course that means I'd
>> have to re-enable triggers on my target DB?
>>
>>
> I remembered Bucardo does multi-master replication. Tried to look on the
> internet how to set it up, but apparently, my RDS PG 12 is already
> considered a "master". So I think there is no reason for me to disable the
> triggers on the target_db. Again, I do not remember where I read this.
>
> Waiting for someone to confirm this...
>
> Lucas
> ___
> Bucardo-general mailing list
> Bucardo-general@bucardo.org
> https://bucardo.org/mailman/listinfo/bucardo-general
>
___
Bucardo-general mailing list
Bucardo-general@bucardo.org
https://bucardo.org/mailman/listinfo/bucardo-general

Re: [Bucardo-general] General Issues Regaring Initial Setup

[Gustavo Tonini]

Hi Rodrigo,
I saw some projects in which the install process is automated. This
 Dockerfile is an example
of an automated installation of bucardo.

Gustavo.

On Thu, Feb 18, 2021 at 1:27 PM Rodrigo Rodovalho <
rodrigo.rodova...@gmail.com> wrote:

> Just for completeness, here is the output from "*bucardo@localhost$
> bucardo install -h localhost --pid-dir /var/run/bucardo --dbuser bucardo
> --dbname bucardo*", run after the creation of a local linux *bucardo*
> user, a database called *bucardo* and a postgres user also called
> *bucardo* with SUPERUSER privileges.
>
> *-*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *This will install the bucardo database into an existing Postgres
> cluster.Postgres must have been compiled with Perl support,and you must
> connect as a superuserCurrent connection settings:1. Host:
> localhost2. Port:   54323. User:   bucardo4. Database:
>   bucardo5. PID directory:  /var/run/bucardoEnter a number to change it, P
> to proceed, or Q to quit: PPassword for user bucardo: Password for user
> bucardo: Attempting to create and populate the bucardo database and
> schemaPassword for user bucardo: Database creation is completeDBI
> connect('dbname=bucardo;host=localhost;port=5432','bucardo',...) failed:
> fe_sendauth: no password supplied at /usr/local/bin/bucardo line 9167.*
> **
>
>
> In my pg_hba.conf:
> (...)
>
> *local all bucardo peer*
> *(...)*
>
>
> Again, thanks
>
> Em qui., 18 de fev. de 2021 às 12:09, Rodrigo Rodovalho <
> rodrigo.rodova...@gmail.com> escreveu:
>
>> Hi,
>>
>> I'm trying to automate deployment of bucardo in a multi-master setup
>> using Ansible.
>>
>> Initially I was manually creating both bucardo's database and user, prior
>> running "bucardo install", but after a few tries I notice that "bucardo
>> install" can do all that if is run with a Postgres SUPERUSER credentials,
>> as follows: "bucardo install -h localhost --pid-dir /var/run/bucardo
>> --dbuser postgres --dbname postgres".
>>
>> The thing is, it keeps asking repeatedly (4 times exactly) for the
>> password of *postgres* user at database level, even though the linux
>> user running the "bucardo install" is the *postgres* user itself and the
>> environment is configured for a peer authentication method from localhost.
>> It should be able to connect to the database with no issues...
>>
>> Just to further clarify, let me list here the installation steps in my
>> Ansible Playbook:
>>
>> 1) Install Bucardo dependencies (For current Debian Stable)
>> 2) Download Bucardo from git
>> 3) Build Bucardo Makefile
>> 4) Make Bucardo
>> 5) Make Install Bucardo
>> 6) Creates local linux bucardo user (not required, no?)
>> 7) Copy *Install Script* (My wrapper script around "bucardo install").
>> This is the script that currently has to feed *postgres* database user's
>> password 4 times to "bucardo install".
>> 8) Create bucardo log and run directories
>> 9) Run *Install Script *as local *postgres* linux user.
>>
>> I've tried, for several days now, run the "bucardo install" with a
>> database bucardo user with SUPERUSER privileges but was unable for several
>> connection issues.
>>
>> I'm at that point that I want first a minimal working setup using Ansible.
>>
>> Postgres 11 and bucardo 5.6.0, btw.
>>
>> Many thanks for the help.
>>
> ___
> Bucardo-general mailing list
> Bucardo-general@bucardo.org
> https://bucardo.org/mailman/listinfo/bucardo-general
>


-- 
Gustavo.
___
Bucardo-general mailing list
Bucardo-general@bucardo.org
https://bucardo.org/mailman/listinfo/bucardo-general