Подтверждение репликации в PostgreSQL + BDR

Question

Я использую библиотеку libpq C для тестирования набора реплик PG + BDR. Я хотел бы получить подтверждение репликации операций CRUD. Моя цель - сделать мой собственный журнал времени репликации в миллисекундах или, если возможно, в микросекундах.

Программа:
Запускает 10-20 потоков с отдельными соединениями, каждая нить выполняет 1000-5000 циклов основных операций CRUD на трех таблицах.

Какой был бы лучший способ?
Разбор некоторых журналов с высокой степенью детализации, если у них есть правильные данные с отметкой времени или в моем C api. Я должен начать N поток (N = {количество узлов} - {мастер, к которому я подключен}) после каждого CRUD op. и запросить узлы для данных.

Answer 1

Вы не можете легко получить подтверждение повторного воспроизведения отдельных xacts. Система отслеживает номер последовательности журналов, воспроизводимый одноранговыми узлами, но не соответствует идентификаторам транзакций, поскольку это не имеет значения.

Возможно, вам нужна почти синхронная или полусинхронная репликация. Там есть какая-то работа для 9.6, которая, надеюсь, принесет пользу BDR вовремя, но это хорошо в будущем.

Между тем вы можете увидеть порядковый номер журнала как restart_lsn в pg_replication_slots. Это не та позиция, к которой воспроизводила реплика, но это самая старая проблема, с которой ей пришлось перезапустить повтор после сбоя.

Вы можете увидеть другие поля LSN, такие как replay_location, только если реплика подключена в pg_stat_replication. К сожалению, в 9.4 нет простого способа узнать, какой слот в pg_replication_slots связан с активным подключением в pg_stat_replication (исправлено в 9.5, но BDR основано на 9.4). Поэтому вам нужно использовать application_name, установленный BDR, если вы хотите выделить отдельные узлы, и это ... «интересно» для синтаксического анализа. Также часто усекается.

Вы можете получить текущий LSN сервера вы совершили XACT на после его совершения по телефону SELECT pg_current_xlog_location(); который будет возвращать значение как 0/19E0F060 или любые другие. Затем вы можете посмотреть это значение в pg_stat_replication узлов-узлов, пока не увидите, что replay_location для узла, на котором вы совершили, достиг или прошел LSN, который вы захватили сразу после фиксации.

Это не идеальный вариант. Между тем, когда вы совершаете фиксацию и когда вы собираете текущий LSN-сервер, может быть проделана другая работа. Вокруг этого нет, но в худшем случае вы слишком долго ждали. Если вы используете BDR, вы все равно не должны заботиться о микро и даже миллисекундах, так как это асинхронное решение для репликации .

Принципы очень похожи на измерение задержки репликации для обычных физических резервных серверов, поэтому я предлагаю прочитать некоторые документы по этому вопросу. За исключением того, что pg_last_xact_replay_timestamp() не будет работать для логической репликации, так что вы не можете получить лаг, используя это, вы должны использовать LSN и делать свою собственную клиентскую часть времени.