Метод аутентификации... LDAP используется только для подтверждения пары «имя пользователя/пароль». Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован LDAP.
Соответственно, нам надо синхронизировать пользователей для того, чтобы
создать пользователей в БД с такими же именами как и в AD
дать этим пользователям в БД права, путем назначения в соответствующие роли в БД
Использовать доменные учетки, а не локальные - хорошая практика с точки зрения ИБ.
SQL файл с миграцией может содержать все, что надо, чтобы перейти из одной версии в другую: alter, create, delete, insert, update...
Сам PGmigrate оперирует файлами-версиями и может сказать какая версия применена, а какая еще нет. Разницу в состоянии базы до и после применения миграций вывести не может.
Могу предложить также ознакомиться с примером из репозитория PGmigrate.
Сами данные в Кафке мы не бекапим, полагаемся на те возможности и гарантии, которые предоставляет сама Кафка. Топики по умолчанию создаются с фактором репликации 3 (и min.insync.replicas=2).
Ноду или кластер мы всегда можем легко восстановить за 10 минут прогнав ansible плейбук в AWX(мы делаем все через ansible: от разметки дисков, до конфигурирования кластера и управления доступом).
Мы зависим от следующий сервисов, чтобы восстановиться:
платформа виртуализации
DNS
AWX
Gitlab (тут лежит inventory для awx, ansible роли, ACL для кластера Kafka и Kafka REST)
Vault (сертификаты, пароли)
Кластерами пользуются большое количество систем. Сервис Kafka, как интеграционная платформа, находится по середине между ИС и является буфером обмена между системами, который развязывает их SLA. Наличие процедуры бекапа данных подразумевает создание периодической процедуры тестирования восстановления. На практике это довольно сложно выполонимо, так как потребуется реализация соответствующей логики для тестирования на стороне систем, использующих Kafka . Плюс, не всем информационным системам это нужно. Поэтому, продолжая аналогию "глупый брокер, умный клиент", мы используем подход "глупый кластер, умная ИС" =). Т.е. это все переносится на уровень дизайна интеграций конкретных информационных систем.
И там уже, если это необходимо, можно:
писать в несколько кластеров (в разных локациях)
иметь процедуру повторной отправки данных за необходимый интервал, а системе-приемнику быть толерантным к дублям (у нас кстати многие системы имеют механику выгрузки исторических данных и повторной отправки данных за необходимый интервал)
dbx-*это доменный пользователь.Процитирую из документации по PostgreSQL. Аутентификация LDAP
Соответственно, нам надо синхронизировать пользователей для того, чтобы
создать пользователей в БД с такими же именами как и в AD
дать этим пользователям в БД права, путем назначения в соответствующие роли в БД
Использовать доменные учетки, а не локальные - хорошая практика с точки зрения ИБ.
SQL файл с миграцией может содержать все, что надо, чтобы перейти из одной версии в другую: alter, create, delete, insert, update...
Сам PGmigrate оперирует файлами-версиями и может сказать какая версия применена, а какая еще нет. Разницу в состоянии базы до и после применения миграций вывести не может.
Могу предложить также ознакомиться с примером из репозитория PGmigrate.
Или вот видео с youtube: PGmigrate — миграции без боли - Евгений Дюков.
Сами данные в Кафке мы не бекапим, полагаемся на те возможности и гарантии, которые предоставляет сама Кафка. Топики по умолчанию создаются с фактором репликации 3 (и min.insync.replicas=2).
Ноду или кластер мы всегда можем легко восстановить за 10 минут прогнав ansible плейбук в AWX(мы делаем все через ansible: от разметки дисков, до конфигурирования кластера и управления доступом).
Мы зависим от следующий сервисов, чтобы восстановиться:
платформа виртуализации
DNS
AWX
Gitlab (тут лежит inventory для awx, ansible роли, ACL для кластера Kafka и Kafka REST)
Vault (сертификаты, пароли)
Кластерами пользуются большое количество систем. Сервис Kafka, как интеграционная платформа, находится по середине между ИС и является буфером обмена между системами, который развязывает их SLA. Наличие процедуры бекапа данных подразумевает создание периодической процедуры тестирования восстановления. На практике это довольно сложно выполонимо, так как потребуется реализация соответствующей логики для тестирования на стороне систем, использующих Kafka . Плюс, не всем информационным системам это нужно. Поэтому, продолжая аналогию "глупый брокер, умный клиент", мы используем подход "глупый кластер, умная ИС" =). Т.е. это все переносится на уровень дизайна интеграций конкретных информационных систем.
И там уже, если это необходимо, можно:
писать в несколько кластеров (в разных локациях)
иметь процедуру повторной отправки данных за необходимый интервал, а системе-приемнику быть толерантным к дублям (у нас кстати многие системы имеют механику выгрузки исторических данных и повторной отправки данных за необходимый интервал)
Планируем опубликовать на следующей недели.