Re: Logical replication issue

From: Pavan Teja <pavan(dot)postgresdba(at)gmail(dot)com>
To: Jayson Hreczuck <jayson(dot)hreczuck(at)studentuniverse(dot)com>
Cc: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: Logical replication issue
Date: 2021-07-30 19:07:40
Message-ID: CACh9nsY5ze3-CGBJRuKnwiOHc7-7nUSKj6tsXSu_mQzhb1mLKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Sat, Jul 31, 2021, 12:14 AM Jayson Hreczuck <
jayson(dot)hreczuck(at)studentuniverse(dot)com> wrote:

> Good afternoon,
>
> We have several different servers and databases all publishing data to one
> large centralized subscriber. However in one of our largest databases,
> we've had issues with the sub after doing bulk inserts on the pub.
>
> We are getting this attempt in logs:
> rep1: 2021-07-30 14:19:15 EDT: :::[111719]:LOG: logical replication apply
> worker for subscription "subrep1_pdx" has started
> rep1: 2021-07-30 14:19:18 EDT: :::[111719]:ERROR: duplicate key value
> violates unique constraint "pk_users"
> rep1: 2021-07-30 14:19:18 EDT: :::[111719]:DETAIL: Key
> (user_id)=(5826051) already exists.
> rep1: 2021-07-30 14:19:18 EDT: :::[65376]:LOG: worker process: logical
> replication worker for subscription 650911835 (PID 111719) exited with exit
> code 1
>
> This issue is that 5826051 does not actually exist on the sub table
> users. I even checked the sequence to see if it was out of sync, and that
> wasn't the case. There seems to be something wrong with the way the data
> is being applied, but I have no idea what would cause this error. This
> table "users", only has inserts and updates, no deletes.
>
> So far the only solution would be a laborious task of wiping the tables
> and doing a complete resync of the subscriber. Given the amount of data
> here, and the slow uncompressed copy command, this takes 16 hours.
>
> Any thoughts and/or suggestions? Is there any quick work around to
> refresh only that one table?
> --
>
>
> *Jayson Hreczuck | Principal Database AdministratorC: +1 617.571.9861*130
> Turner St, Ste 530, Waltham, MA 02453
>

Hi Jay,

Might be creating a separate publication/subscription for that table alone
might resolve the risk resyncing the complete subscriber data. Just a
thought.

Regards,
Pavanteja,
9841380956

>
>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Thorsten Schöning 2021-08-01 09:51:58 Re: What's the dfifference between pg_start_backup+copy+pg_stop_backup+WAL vs. pg_start_backup+pg_stop_backup+copy+WAL?
Previous Message Jayson Hreczuck 2021-07-30 18:44:13 Logical replication issue