Informix to Postgres, алгоритм непрерывной репликации данных

Question

Главный сервер Informix, версия варьируется от 9.40 до последней, база данных - . Неразработано по дизайну, которое невозможно изменить. Slave-сервер - это последний PostgreSQL. Master и slave являются отдельными машинами, сетевая латентность непредсказуема. Мастер-схема статически определена, хорошо известна и не изменяется, поэтому нужно реплицировать только данные. В магистратуре есть три типа таблиц:

1. Числовые таблицы данных, обычно один столбец даты, одноразовый столбец и 15-300 int столбцов с ключом 2-3 первичных ключей. Данные никогда не изменяются, добавляются только один раз в заданный интервал (15, 30 или 60 минут) и удаляются при достижении точки сохранения. Набор данных репликации может составлять до 80 000 строк, но обычно он находится в диапазоне от сотен. Эти данные должны быть реплицированы в одну сторону, ведущие к подчиненным. Существует около 30 таблиц этого типа, и их необходимо реплицировать сразу и как можно быстрее, обычно через одну минуту после того, как новый набор интервалов был передан мастеру.
2. Таблицы смешанных данных с датами, временем, int и строковыми типами, 30-100 столбцов, еще 2-3 первичных ключа. Эти данные также никогда не меняются, добавляются непрерывно и удаляются при достижении точки хранения. Набор данных составляет до 100 000 строк в час. Требуется односторонняя репликация, мастер-подчиненный. Есть несколько таблиц, как правило, менее 5.
3. Таблицы смешанных данных, содержащие типы int и string, менее 10 столбцов, 2-3 первичных ключа. Данные в значительной степени остаются нетронутыми, со случайными добавлениями, изменениями или удалениями. Обычный размер набора реплик непредсказуем, но, вероятно, будет содержать несколько сотен строк. Эти данные должны быть скопированы в обе стороны, как можно быстрее. Существует несколько таблиц этого типа, и их необходимо синхронизировать независимо.

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

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

1. Пожар триггера мастера изменений, запись строк OIDs (? Делает Informix есть) на временную таблицу, сбросить измененные строки в файл, передать его и загрузить. Вопрос: как буферировать триггер? Мастер-БД не имеет разметки (без транзакций), поэтому триггер будет срабатывать при каждом INSERT. Дополнительная нагрузка на мастера, не хорошая.
2. Добавьте задание cron на подчиненное устройство, которое вытащит последние ключи даты/времени из мастера, и если данные новее, потяните его. Проблема: хотя интервал обновления определен, на самом деле он основан на источнике данных (а не на часах базового БД), который, как гарантируется, может меняться от часов ведомого сервера. Более того, может быть несколько источников данных, каждый из которых имеет разные часы, и данные необходимо реплицировать как можно скорее. Единственный способ, который я вижу, это постоянно опросить мастера от подчиненного, надеясь, что к моменту опроса данных данные будут все совершены (транзакций, помните?). Kludgy, медленно, не хорошо.
3. Добавить Informix в качестве внешней оболочки данных в Postgres и запускать запросы непосредственно вместо того, чтобы беспокоиться о репликации. Плюсы: простота. Минусы: коннектор Informix, похоже, находится в альфа-стадии, и весь подход в лучшем случае неизвестен.

Я изучал эту тему в течение некоторого времени, и кажется, что ядром проблемы является отсутствие транзакций на стороне мастера.Если бы ведущая БД была зарегистрирована, было бы намного проще ее копировать, но без транзакций задача внезапно становится намного сложнее. Во-первых, как я могу гарантировать, что нет обманов? Другой, как избежать циклов обновления в таблицах типов 3? Учитывая все это, как сделать репликацию максимально быстрой реакцией? Я имею в виду задержку между обновлением данных и началом синхронизации, передача данных - это еще одна тема.

Любые данные приветствуются.

Answer 1

Если вы не можете изменить мастер каким-либо значительным образом, у вас будет какое-то время с любой репликацией. Ваша основная проблема заключается в том, что у вас нет реального способа обработки репликации изменений в реальном времени, не отслеживая, какие изменения были реплицированы, и если вы не можете изменить мастер, вы не можете добавить это. Таким образом, короткий ответ заключается в том, что репликация не является решением, которое может работать на вас. Учитывая некоторые другие особенности Informix, я бы дважды подумал об этом как о непрерывной репликации.

Это приводит к другим подходам. Большие неизвестные факторы заключаются в том, что сети могут быть недостаточно надежными, чтобы просто связывать базы данных. Это может привести к тому, что транзакции будут висящими, ожидая передачи данных с высокой задержкой на все другие проблемы. Возможно, вы сможете заставить это работать с fdw odbc и поставщиком Informix или с DBI-Link и DBD :: Informix, но это ставит меня как проблему в вашей текущей среде. Вы могли бы использовать их в задании cron, чтобы периодически заполнять второй сервер PostgreSQL ближе к вашему собственному местоположению, и поэтому я бы не полностью отписал этот подход.

Так или иначе мне кажется, что вам нужно получить копию данных на ваш сервер PostgreSQL. Вы можете захотеть выполнить задание ETL для периодического импорта данных. Вы можете использовать вторичный сервер postgresql и FDW или DBI-Link для загрузки данных. Но это вряд ли будет в режиме реального времени, оно вряд ли будет непрерывным.

Tl; dr - это то, что ваша среда не настроена для этого. За свои деньги я бы рекомендовал подход ETL и согласился с тем, что ваше подчиненное устройство не будет синхронизироваться с мастером.