Top.Mail.Ru

Вопросы и ответы по решению “Датафлот Репликация”, часть 2

Первая часть вопросов и ответов можно прочитать здесь.

  1. Как реализована многопользовательская работа над одним и тем же проектом?

В данный момент многопользовательская работа внутри одного проекта не поддерживается.

2. Таблица может храниться в облаке?

Да, если возможно организовать соответствующее подключение (указав имя хоста, порт, имя БД и т.п.)

3. Возможна ли динамическая репликация?

Если под динамической репликацией понимается автоматическое добавление в репликацию новых таблиц, то такая репликация возможна при использовании DDL репликации. При этом в зависимости от типа источника могут быть свои особенности. Например, для Oracle при создании таблицы нужно будет добавлять ее в supplemental log либо включить опцию автодобавления на уровне БД. Для Postgres такие действия не потребуются.

4. Если добавить колонку в таблицу, то она подхватится автоматически при выборе опции захвата данной операции?

Да, если включить репликацию DDL.

5. Возможно ли игнорирование захвата определенных данных?

Да, поддерживаются возможности фильтрации на уровне источника по значениям колонок (парсер будет добавлять соответствующие условия WHERE),  а также при записи в приемник с использованием выражений SQL или скриптов TCL.

6. Будет ли создана новая колонка в таблице источнике или её необходимо будет добавить руками?

Да, будет создана и в источнике, и в приемнике. Для этого в проекте необходимо включить дополнительно репликацию DDL.

7. Возможна ли двунаправленная (мультимастер) репликация?

Да, двунаправленная репликация возможна. Также есть возможность управления разрешением конфликтов.

8. Чем вариант репликации История отличается от Хранилища?

В режиме “История” на приемнике создается таблица аудита.  В таблицу журнала аудита записывается строка для каждой SQL-операции обновления, вставки или удаления в исходной таблице. В каждой строке таблицы аудита хранятся метаданные об операции SQL, а также снимки before- и after- данных для каждого столбца замаппированной таблицы.

В режиме “Хранилище” каждая таблица-источник имеет соответствующую таблицу-приемник и соответствующую таблицу журнала аудита в приемнике.

Перед запуском репликации в режиме Хранилище необходимо выполнить первоначальную синхронизацию, синхронизирующую данных источника и приемника.

При репликации изменений Загрузчик аккумулирует изменения для цикла загрузки в таблицах журнала аудита, объединяет изменения в меньшее количество операторов SQL, а затем применяет изменения к таблицам-приемникам. Таблицы журнала аудита очищаются в начале каждого цикла Загрузки. Т.е., другими словами, загрузка в таблицы-копии осуществляется мини-пакетами на основе данных таблиц аудита.

Вы можете использовать режим Хранилище для репликации данных в приемники Greenplum, Netezza, Oracle, Teradata и Vertica.

9. Что будет если архивные логи “протухли”

В случае, если данные архивных логов потеряны по каким-либо причинам до того, как парсер Датафлот успел их обработать, необходимо либо заново выполнять полную синхронизацию как при начале работы решения средствами Датафлот, либо каким-то образом синхронизировать данные источников и приемников сторонними средствами с последующим указанием парсеру с какого SCN/LSN он должен продолжить чтение логов.

10. Зависимости в расписании могут быть?

Да, можно настроить зависимости одних задач от других.

11. Канал оповещения (рассылки уведомлений) только почта?

На данный момент поддерживаются рассылки уведомлений по email и SNMP протоколу.

12. Какие минимальные/оптимальные аппаратные требования к серверной части? Под управлением какой ОС работает серверная часть?

Решение работает на ОС Linux (проверены в т.ч. российские варианты Astra и Alt) и windows (актуально для источников с MS SQL).

Рекомендуемая начальная конфигурация сервера для проведения пилотов при использовании выделенного сервера для Датафлот Репликации: Linux сервер, от 4 ядер CPU, от 16 GB RAM, диск от 500 GB. Если объемы изменений большие, то дисковое пространство нужно планировать в соответствии с планируемым объемом обрабатываемых изменений. Как минимум объем диска должен иметь возможность хранить в буфере ежедневные объемы журналов изменений за несколько дней.

13. Есть ли данные по времени отставания от источника?

Это очень индивидуальная история, зависящая от многих факторов – нагрузка и интенсивность изменений на источнике, дисковая подсистема хранения журналов, частота процессора парсера, способность приемника своевременно принимать соответствующий объем изменений  и т.п. Если “узких” мест нет, то сколько-нибудь заметного отставания практически не будет.

Пожалуйста, свяжитесь с представителями DIS Group, если вы заинтересованы в пилотировании решения Датафлот в вашем окружении.

14. Создаются ли временные объекты? Если да, то где хранятся?

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

15. Как реализован аудит действий пользователей? Есть выгрузка лога аудита для ИБ?

Действия сохраняются в системном журнале. Какой-то специальной выгрузки для ИБ на данный момент нет, но этот вопрос находится в проработке.

16. Как технически выполняется инициализирующая выгрузка? В одну JDBC-сессию?

Для выгрузки и загрузки в зависимости от типа источника и приемника используются ODBC, нативные клиенты БД (например OCI) и нативные утилиты bulk загрузки  и библиотеки приемников (например, libpq). JDBC не используется.  Выгрузка и загрузка происходят в рамках одного процесса.

17. В enterprise, обычно, на продуктовом контуре, делать руками ничего нельзя. Как релизован процесс передачи конфигурации с тестового контура на препрод/прод? Можно ли переносить конфигурации Датафлот между средами (дев/тест/прод)?

Да, есть механизмы экспорта/импорта проектов.

18. Можно ли сохранять конфигурации в Git?

Какой-то специальной интеграции с Git нет. Конфигурация представляет собой бинарный файл, необходимость интеграции с Git не очевидна.

19. Есть ли ограничения для той или иной СУБД источника/приемника?

По каждому типу источника и приемника могут быть свои особенности. Все они подробно описаны в документации.

20. Захват транзакционный, если да то, как обстоят дела с долгими транзакциями (несколько часов)?

Используется “оптимистичная” стратегия – парсер читает и передает в буфер все данные, относящиеся к нужным таблицам, подразумевая, что транзакция закомитится с более высокой вероятностью чем откатится. В случае если произойдет роллбэк, то Загрузчик просто не будет применять соответствующие изменения на приемнике.

21. Может ли одна таблица быть приемником из нескольких источников?

Да, технически это возможно. Потребуется создать несколько проектов. Кроме того, необходимо будет решить организационные вопросы с первоначальной синхронизацией и потенциальными конфликтами (например, при  дублировании primary key).

22. Как происходит репликация DDL-операций при гетерогенной репликации, например Oracle>PostgreSQL, в частности как перекодируются типы?

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

23. Есть ли тесты производительности по сравнению с Debezium

Да, проведен ряд сравнительных тестов. По результатам тестирования решение Датафлот Репликация показало выигрыш в скорости первоначальной синхронизации от 282 до 343 раз, выигрыш в скорости репликации изменений от 11 до 26 раз. Также, например, работа с использованием собственного парсера Датафлот при работе с источником Postgres значительно быстрее работы через API Postgres которое использует Debezium (парсер Датафлот быстрее в 7–11  раз по результатам тестов). Кроме того, парсер Датафлот значительно меньше (в 8–10 раз по результатам тестов) нагружает сервер источник Postgres.

24. Есть ли интеграция пользователей с AD, kerberos, openId и т.п.?

На данный момент нет. Есть планы по интеграции с LDAP.

25. Поддерживается ли транзакционность при распараллеливании загрузки,  например данные в мастер таблицу и детальную таблицу попадают в одной транзакции?

Транзакционность в смысле обработки только закоммиченных в рамках одной транзакции данных поддерживается. Однако при использовании многопоточной загрузки в приемник соблюдение порядка, например для появления primary и foreign keys в разных таблицах в общем случае не гарантируется. Для некоторых БД (например, Oracle) существует возможность решить проблему зависимостей при появлении primary и foreign keys при многопоточной загрузке в приемник с использованием deferred constraints и применением глобального коммита по всем потокам.

26. Порядок применения транзакций на приемнике соответствует  порядку источника?

Загрузчик будет считывать данные о транзакции из буфера в порядке их применения. В случае однопоточной загрузки в приемник порядок будет соответствовать. Однако при использовании многопоточной загрузки в приемник соблюдение порядка, например для появления primary и foreign keys в общем случае не гарантируется. Для некоторых БД (например, Oracle) существует возможность решить проблему зависимостей при появлении primary и foreign keys при многопоточной загрузке в приемник с использованием deferred constraints и применением глобального коммита по всем потокам.


Поделиться
{{ responsive_img( url='/../../static/upload/news/detail-image.jpg',lazy=true, img_attrs={ class: "img-fluid lazy" }, formats=['webp'] ) }}

Рассылка новостей

    Продолжая пользоваться сайтом, вы даёте Согласие на автоматический сбор и анализ ваших данных, необходимых для работы сайта и его улучшения, использование файлов cookie.