Pull to refresh

Comments 10

UFO just landed and posted this here
Да, WAL собственно и есть транзакционный лог. Копировать логи раз в минуту совершенно не обязательно: в PostgreSQL замечательно работает streaming-репликация как асинхронная так и синхронная. Последняя не вносит дополнительных издержек к commit, кроме времени сетевого latency.
Тема очень интересная, но статья явно не полная. Добавили бы побольше примеров. Возможно, ссылки на документацию или какие-то похожие статьи.

Документация как мне кажется не права, так как рекомендует задирать значение xid в максимальное значение при использовании pg_resetxlog. Я руководствуюсь тем, что лучше иметь консистентную картину сразу после checkpoint, чем последние полу-записанные (только вытесненные из shared buffers) данные и удаленный xlog.


У статьи будет продолжение — мы напишем маленькую утилиту, с помощью которой можно будет создать/переписать pg_control, чтобы можно было воспользоваться стандартным механизмом восстановления после сбоя.

Спасибо за ответ
будем ждать с нетерпением продолжения и утилиту )))
UFO just landed and posted this here

Можно поднять больше: под 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 — большой вопрос. Как мне кажется это мусорные данные, которыми нельзя пользоваться.

Select вызывает запись при обновлении страниц после hot-update
Select вызывает запись при обновлении страниц после hot-update

select всегда вызывает запись (переписывает страницы при full_page_write) если находит закомиченные в clog, но не помеченные как закомиченные данные в data.

Sign up to leave a comment.