Чтобы отслеживать задержку репликации с одного сервера PostgreSQL на другой, я использую простой сценарий, который выполняет запрос «SELECT pg_current_xlog_location ()» на главном сервере и «SELECT pg_last_xlog_receive_location ()» на подчиненном сервере. Затем я конвертирую результаты из шестнадцатеричного числа в десятичные и вычисляю разницу, чтобы получить задержку репликации.
Моя проблема в том, что я не могу понять, в каких единицах возвращается это xlog_location. Кто-нибудь может это объяснить?
«Единицы измерения не имеют значения» (но если вам интересно, единицы измерения позиция в журнале транзакций - есть небольшая дискуссия Вот).
Важно отметить, что есть Нет положительная корреляция между положением бревна и временем.
Крупные транзакции могут значительно продвинуть журнал вперед за короткий период.
Слегка используемые базы данных могут находиться в одной точке журнала в течение нескольких часов (или дольше).
Все, что вы можете узнать из этого измерения, - это то, насколько вы отстаете в журнале (т.е. синхронизированы ли вы с мастером или нет, и примерно сколько данных необходимо отправить / воспроизвести).
Есть еще обсуждение здесь, в Postgres Wiki, но, судя по вашему вопросу, я думаю, вы уже читали эту страницу - возможно, стоит спросить на Postgres список рассылки pgsql-admin для разъяснения (и вы можете найти лучший ответ, чем то, что я вам дал, и, возможно, также сможете обновить Postgres Wiki :-)
Единицы журнала - в байтах (хотя они относительны - поэтому они не полезны для измерения чего-либо, кроме «смещений», и иногда могут быть «скачки», когда много пропущенных байтов), при этом значение вычисляется как :
Если вы возьмете вывод: SELECT pg_current_xlog_location (), вы получите что-то вроде:
70/A9002358
Часть перед "/" умножается на 'ff000000' и добавляется ко второй части:
на языке Python (преобразование шестнадцатеричного в с помощью функции int ('HEX', 16)), который может выглядеть так:
int('ff000000',16)*int('70',16) + int('A9002358',16)
Вы можете найти текущее имя используемого файла WAL, используя:
select pg_xlogfile_name(pg_current_xlog_insert_location());
Технически это «возможно» для ведомого устройства догнать ведущего, если файлы журнала, которые необходимы ведомому устройству, все еще доступны на ведущем устройстве. Конечно, если ведомое устройство воспроизводит медленно, оно может никогда не догнать его, но вы можете измерить, «догоняет» он или «отстает» (вроде как), используя следующий запрос:
На ведомом устройстве вы можете получить представление о временной задержке с помощью запроса:
SELECT extract(epoch from (now()-
pg_last_xact_replay_timestamp())) AS time_lag;
Однако возвращаемое число на самом деле является «временем, прошедшим с момента последней воспроизведенной транзакции от ведущего устройства» - поэтому, если ведущее устройство не выполняло транзакцию в течение некоторого времени, это «время» может создать впечатление, что ведомое устройство отстает (когда оно в действительности, он догнал, но на мастере не было транзакций.)