Comments 10
Документация как мне кажется не права, так как рекомендует задирать значение xid в максимальное значение при использовании pg_resetxlog. Я руководствуюсь тем, что лучше иметь консистентную картину сразу после checkpoint, чем последние полу-записанные (только вытесненные из shared buffers) данные и удаленный xlog.
У статьи будет продолжение — мы напишем маленькую утилиту, с помощью которой можно будет создать/переписать pg_control, чтобы можно было воспользоваться стандартным механизмом восстановления после сбоя.
будем ждать с нетерпением продолжения и утилиту )))
Можно поднять больше: под shared_buffers
выделен конечный размер RAM и измененные данные эпизодически вытесняются на диск до процесса создания контрольной точки, поэтому select-запрос может вызвать запись (обратите внимание на written):
postgres=# explain (analyze,buffers) select max(bid) from pgbench_accounts;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=28894.00..28894.01 rows=1 width=4) (actual time=183.727..183.727 rows=1 loops=1)
Buffers: shared hit=2176 read=14218
-> Seq Scan on pgbench_accounts (cost=0.00..26394.00 rows=1000000 width=4) (actual time=0.045..97.754 rows=1000000 loops=1)
Buffers: shared hit=2176 read=14218
Planning time: 0.068 ms
Execution time: 183.752 ms
(6 строк)
postgres=# update pgbench_accounts set bid = bid +1;
UPDATE 1000000
postgres=# explain (analyze,buffers) select max(bid) from pgbench_accounts;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=57786.24..57786.25 rows=1 width=4) (actual time=8688.176..8688.176 rows=1 loops=1)
Buffers: shared hit=191 read=32596 dirtied=32787 written=1883
-> Seq Scan on pgbench_accounts (cost=0.00..52786.39 rows=1999939 width=4) (actual time=3807.514..8598.292 rows=1000000 loops=1)
Buffers: shared hit=191 read=32596 dirtied=32787 written=1883
Planning time: 0.052 ms
Execution time: 8688.195 ms
(6 строк)
postgres=#
Что будет записано в таком случае после checkpoint — большой вопрос. Как мне кажется это мусорные данные, которыми нельзя пользоваться.
Восстановление данных PostgreSQL после потери pg_control