From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Josef Machytka <josef(dot)machytka(at)gmail(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: error: database is not accepting commands to avoid wraparound data loss in database .... |
Date: | 2019-03-20 14:59:44 |
Message-ID: | a3f8e93f958d137bf95f2f1367f046e28bb2dd45.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wed, 2019-03-20 at 12:01 +0100, Josef Machytka wrote:
> I checked solution for wraparound error and since all sources I found
> suggested to do VACUUM under single-user mode I decided to test it on
> second smaller data warehouse database (~16TB of data) which is not so
> crucial for us to have it still running since I knew it will be inaccessible
> during that time. Vacuum is running for 24 hours already on this database
> and I can only wait for it to finish....
>
> Can I do something else with main data warehouse database than just this
> painfully slow VACUUM? If I would change some settings for freeze would
> it help in way that database would accept commands again so I would be
> able to drop subscription and vacuum it in normal way?
One this happen, all you can do it wait for the manual VACUUM to finish.
Don't interrupt it.
The alternative (losing your data to corruption) is more painful than
this outage.
If you perform database backups with pg_dump, one faster solution with little
data loss would be to restore such a backup. The resulting database will
not be bloated.
To prevent this from happening, monitor database bloat and tune autovacuum
to be more aggressive if necessary.
If your load is mostly UPDATEs, see ig you can make use of the HOT update
feature.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Schmidt | 2019-03-20 20:37:31 | AW: PostgreSQL high availability solutions for high rates. |
Previous Message | Thomas Kellerer | 2019-03-20 13:34:56 | Re: PostgreSQL high availability solutions for high rates. |