Глава 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 type

  • mvarchar — analog of the MS SQL varchar type

F.28.3. MCHAR and MVARCHAR features

  • Defines length(str) function

  • Defines substr(str, pos[, length]) function

  • Defines || operator, which would be applied to concatenate any (mchar and mvarchar) arguments

  • Defines set of operators: <, <=, =, >=, > for case-insensitive comparison (ICU)

  • Defines set of operators: &<, &<=, &=, &>=, &> to case-sensitive comparison (ICU)

  • Implicit cast between mchar and mvarchar types

  • B-tree and Hash-index support

  • The LIKE [ESCAPE] operator support

  • The SIMILAR TO [ESCAPE] operator support

  • The ~ operator (POSIX regexp) support

  • Index support for the LIKE operator

F.28.4. Authors


      Oleg Bartunov 
      Teodor Sigaev