Greetings,
* Abdul Qoyyuum (aqoyyuum@cardaccess.com.bn) wrote:
> Knowing that it's a data corruption issue, the only way to fix this is to
> vacuum and reindex the database. What was suggested was the following:
>
> SET zero_damaged_pages = 0; # This is so that we can have the application
> to continue to run
> VACUUM FULL VERBOSE ANALYSE; # Do a full vacuum and analyse the problem if
> possible.
> REINDEX DATABASE "core"; # Then do a reindex and clean it up.
This is only going to help if the issue is in an index, which isn't
clear from what's been shared.
> We're on Postgresql 12. This has worked before it happened (almost exactly
> a year ago) and I think this needs a more permanent solution. I've looked
> at routine vacuuming and checked the autovacuum is set to on and the
> following configurations:
This isn't something that should ever happen ...
This also doesn't have anything to do with autovacuum, changing settings
there won't make any difference.
> Can anyone advise if there's anything else we can do? We have no clue what
> causes the invalid page block and we are running a High Availability
> cluster set up but we are hoping that there may be a way to mitigate it.
Was there some kind of hardware fault? Did you do a failover? Restore
from a backup? Do you have checksums enabled? How many times has this
happened before, and how many pages were impacted? What is the design
of your HA solution, are you using PG replication or something else?
Thanks,
Stephen