Re: Incorrect snapshots while promoting hot standby node when 2PC is used
От | Andres Freund |
---|---|
Тема | Re: Incorrect snapshots while promoting hot standby node when 2PC is used |
Дата | |
Msg-id | 20210503181050.d5jockbtljjgphu7@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Incorrect snapshots while promoting hot standby node when 2PC is used (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: Incorrect snapshots while promoting hot standby node when 2PC is used
|
Список | pgsql-hackers |
Hi, On 2021-05-01 17:35:09 +0500, Andrey Borodin wrote: > I'm investigating somewhat resemblant case. > We have an OLTP sharded installation where shards are almost always under rebalancing. Data movement is implemented with2pc. > Switchover happens quite often due to datacenter drills. The installation is running on PostgreSQL 12.6. If you still have the data it would be useful if you could check if the LSNs of the corrupted pages are LSNs from shortly after standby promotion/switchover? > Can this case be related to the problem that you described? It seems possible, but it's hard to know without a lot more information. > Or, perhaps, it looks more like a hardware problem? Data_checksums are > on, but few years ago we observed ssd firmware that was loosing > updates, but passing checksums. I'm sure that we would benefit from > having separate relation fork for checksums or LSNs. Right - checksums are "page local". They can only detect if a page is corrupted, not if e.g. an older version of the page (with correct checksum) has been restored. While there are schemes to have stronger error detection properties, they do come with substantial overhead (at least the ones I can think of right now). Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: