PostgreSQL: Случай в вакууме

выполнена и их номера хранить не надо

именно это и делает процесс вакуум, он проставляет специальный номер транзакции — FrozenXid (так было до 9.5), а в 9.5 проставляется специальный Hint Bit.

Вопрос к тому, что разве нельзя по достижению середины круга проходить по всему счетчику

счетчик прописал свой номер в данных, и идти надо по данным, а не по счетчику. На больших данных это накладно. Поэтому существуют процессы, которые выполняют это в фоне.

Таким образом, мы сохраним порядок ­транзакций, что нам и требовалось?

в идеале все работает "само", факап описанный в статье произошел из-за того, что 8 дней выполнялся процесс работающий в своем снимке данных, можно сказать в своей транзакции.

PostgreSQL в Azure. Часть 1

Идею подсказали парни из https://www.avito.ru/

PostgreSQL в Azure. Часть 1

Я тестирую haproxy + pgsql extension. Но возвращение на старый мастер не получиться. Данные старого мастера нужны для разбирательства администратору.

PostgreSQL в Azure. Часть 1

Спасибо за комментарий!
Мы собираемся написать про авто-файловер где-то в 3 части.

Восстановление данных PostgreSQL после потери pg_control

Что будет записано в таком случае после checkpoint — большой вопрос. Как мне кажется это мусорные данные, которыми нельзя пользоваться.

Восстановление данных PostgreSQL после потери 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=# 

Восстановление данных PostgreSQL после потери pg_control

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

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

Восстановление данных PostgreSQL после потери pg_control

Да, WAL собственно и есть транзакционный лог. Копировать логи раз в минуту совершенно не обязательно: в PostgreSQL замечательно работает streaming-репликация как асинхронная так и синхронная. Последняя не вносит дополнительных издержек к commit, кроме времени сетевого latency.

PostgreSQL на многоядерных серверах Power 8

имел ввиду эффективнее обойти софтово.

PostgreSQL на многоядерных серверах Power 8

По нашим оценкам, в условиях этого теста, NUMA (запускаем все процессы сервера на одной numa-ноде, а память на крайней по растоянию) давала деградацию 10-20%.

И «huge drop in performance when going from 15-cores on1-socket to 30-cores on 2-socket» как описано тут:
https://events.linuxfoundation.org/sites/events/files/slides/linuxcon-2014-locking-final.pdf мы не наблюдали.

Большая часть проблемы — не хардваная, а софтовая — это синхронизация экслюзивного доступа к ресурсу — странице памяти. Эту проблему мы и решали.

PostgreSQL на многоядерных серверах Power 8

Мы увеличивали sched_migration_cost в 50 раз. Биндингом на ноды занимался numactl.

PostgreSQL на многоядерных серверах Power 8

Держите: https://gist.github.com/vadv/b6dc474ded1261a5b643
В gist'е находится часть с необходимым ddl и питоновским скриптом, надстройкой над pgbench.
Результаты тестирования хранятся в базе results.

PostgreSQL на многоядерных серверах Power 8

>индексы вручную

кстати можно и так:

postgres=# create table t (i int);
CREATE TABLE
postgres=# create index t_idx_i on t(i);
CREATE INDEX
postgres=# create table child_1_t (like t including indexes) inherits(t);
NOTICE:  merging column "i" with inherited definition
CREATE TABLE
postgres=# \d+ child_1_t
                      Table "public.child_1_t"
 Column |  Type   | Modifiers | Storage | Stats target | Description 
--------+---------+-----------+---------+--------------+-------------
 i      | integer |           | plain   |              | 
Indexes:
    "child_1_t_i_idx" btree (i)
Inherits: t

PostgreSQL на многоядерных серверах Power 8

1. Сделать человеческий партишининг есть в планах, но пока и без этого postgresql не хватает более важных вещей: awr, заморозка планов, трасировка…
Вот буквально вчера был внутренний семинар, где наш разработчик представил рабочее решение по статистике, которая предоставляется для планера и ее миграции в другие инстансы/версии postgresql.
Если не ошибаюсь, на прошлой неделе Юра Журавлев представил уже рабочее решение по прикреплению планов к конкретным запросам и экспорт на другие машины.

2. Нормальный фенсинг дает peacemaker, об этом был один из наших докладов на HL: http://www.slideshare.net/AlekseyChizhkoff/dancing-cluster, скоро будет рекомендованый пакеты. К сожалению, а может быть к счастью, встраивать такое решение в поставку с «базой» такое решение сообщество не пойдет. Дополнительно мы проталкиваем патчи такого рода: failover на уровне протокола клиента, read-only на уровне протокола.

PostgreSQL на многоядерных серверах Power 8

Это было не сложно, основные инструменты: perf && gdb:

Про perf вы можете почитать подробнее тут: https://wiki.postgresql.org/wiki/Profiling_with_perf

GDB использовали потому что perf не мог построить за приемлемое граф вызовов, для этого в gdb необходимо вызвать backtrace:
gdb --batch --command=file.script --pid $PID_OF_BACKEND

PostgreSQL на многоядерных серверах Power 8

>всё надо делать вручную
у вас недостаточный опыт общения с PostgreSQL. откройте для себя экстеншены.

PostgreSQL на многоядерных серверах Power 8

> wiki.postgresql.org/wiki/PGStrom
я не говорил про конкретный проект. вы можете написать небольшой кусок кода, которую обвяжете в функцию, которую вы можете отправить на Phi.

>2,3. не имеет существенного для меня значения
Энтерпрайз до этого еще не дорос.

>чем бинарное хранение в файловой системе не устраивает для 3?
что вы имеете ввиду?

PostgreSQL на многоядерных серверах Power 8

я говорил про завязаность на вендора, к сожалению вы этого видете, или не хотите замечать.

PostgreSQL на многоядерных серверах Power 8

>Вот потому и удивляет, что не находят времени из коробки дописать логику failover-ов и heartbeat-ов и для этого приходится писать своё приложение

а отдавать по 50k $ за ядро вас не удивляет? :)

PostgreSQL на многоядерных серверах Power 8

И да, привет от ORA-600 ;)