Глава 49. Отслеживание прогресса репликации
Инфраструктура источников репликации введена для упрощения реализации решений логической репликации на основе логического декодирования. Она помогает решить две распространённых проблемы:
Как надёжно отслеживать прогресс репликации
Как менять поведение репликации в зависимости от источника строки; например, для предотвращения циклов при двунаправленной репликации
Источники репликации имеют только два свойства: имя и OID. Имя, по которому к источнику следует обращаться из разных систем, задаётся значением типа text
в произвольной форме. Его следует выбирать так, чтобы конфликты между источниками репликации, созданными различными средствами репликации были маловероятны; например, добавлять в начало обозначение средства репликации. OID используется только для того, чтобы не приходилось хранить длинное имя там, где требуется минимизировать объём. Он не может разделяться между разными системами.
Источник репликации можно создать функцией pg_replication_origin_create()
; удалить функцией pg_replication_origin_drop()
; и увидеть в системном каталоге pg_replication_origin
.
Одной из нетривиальных задач при организации репликации является надёжное отслеживание прогресса воспроизведения. Например, когда применяющий изменения процесс (или весь кластер) умирает, нужно иметь возможность понять, какие данные были переданы успешно. Наивные решения этой проблемы, такие как изменение строки в некоторой таблице для каждой воспроизведённой транзакции, чреваты дополнительной нагрузкой во время выполнения и замусориванием базы данных.
С использованием инфраструктуры источников репликации сеанс может быть помечен как воспроизводящий изменения с удалённого узла (с помощью функции pg_replication_origin_session_setup()
). В дополнение к этому для каждой транзакции из источника можно задать LSN и время фиксации, вызвав pg_replication_origin_xact_setup()
. Если сделать всё это, прогресс репликации можно будет отслеживать надёжным образом. Прогресс воспроизведения для всех источников репликации можно увидеть в представлении pg_replication_origin_status
. Прогресс отдельного источника, например, при возобновлении репликации, можно получить для любого источника, воспользовавшись функцией pg_replication_origin_progress()
, или для источника, настроенного в текущем сеансе, с помощью pg_replication_origin_session_progress()
.
В топологиях репликации более сложных, чем простая репликация с одной системы в другую, возможна ещё одна проблема — повторная репликация уже воспроизведённых строк, что может приводить к зацикливанию и снижению эффективности. В качестве механизма выявления и предотвращения повторной репликации так же могут оказаться полезны источники репликации. Если воспользоваться функциями, упомянутыми в предыдущем абзаце, во все поступающие в сеансе транзакции и изменения, передаваемые обработчикам модулей вывода (см. Раздел 48.6), добавляется пометка источника репликации для текущего сеанса. Это позволяет обрабатывать их в модуле вывода по-разному, например, игнорировать все строки, кроме имеющих локальное происхождение. Кроме того, обработчик вызова filter_by_origin_cb
позволяет отфильтровать поток изменений логического декодирования в зависимости от источника. Фильтрация через этот обработчик не так гибка, как проверка записей внутри модуля вывода, но зато гораздо эффективнее.
F.28. mchar
The mchar
module provides additional data types for compatibility with Microsoft SQL Server (MS SQL).
F.28.1. Overview
This module has been designed to improve 1C Enterprise support, most popular Russian CRM and ERP system.
It implements types MCHAR and MVARCHAR, which are bug-to-bug compatible with MS SQL CHAR and VARCHAR respectively. Additionally, these types use the ICU library for comparison and case conversion, so their behavior is identical across different operating systems.
Postgres Pro also includes citext extension which provides types similar to MCHAR. But this extension doesn't emulate MS-SQL behavior concerning end-of-value whitespace.
Differences from Postgres Pro standard CHAR and VARCHAR are:
Case insensitive comparison
Handling of the whitespace at the end of string
These types are always stored as two-byte unicode value regardless of database encoding.
F.28.2. Additional types
mchar
— analog of the MS SQL char typemvarchar
— analog of the MS SQL varchar type
F.28.3. MCHAR and MVARCHAR features
Defines
length(str)
functionDefines
substr(str, pos[, length])
functionDefines
||
operator, which would be applied to concatenate any (mchar and mvarchar) argumentsDefines set of operators:
<
,<=
,=
,>=
,>
for case-insensitive comparison (ICU)Defines set of operators:
&<
,&<=
,&=
,&>=
,&>
to case-sensitive comparison (ICU)Implicit cast between
mchar
andmvarchar
typesB-tree and Hash-index support
The
LIKE [ESCAPE]
operator supportThe
SIMILAR TO [ESCAPE]
operator supportThe ~ operator (POSIX regexp) support
Index support for the LIKE operator
F.28.4. Authors
Oleg Bartunov <oleg@sai.msu.ru>
Teodor Sigaev <teodor@sigaev.ru>