 Синхронизация содержимого таблицы для PostgreSQL 9.1,  xintrea, 04-Мрт-20, 16:30 [смотреть все]Ковыряюсь сейчас с древним Astra Linux 1.3 (Debian Wheezy с ядром 3.2.0), и нужно мне сделать синхронизацию идентичных таблиц на 5-ти хостах.Таблицы имеют идентичную структуру. Есть поля: PRIMARY KEY id,
TIMESTAMP,
UUID,
прочие поля Содержимое записей не меняется. Синхронизация должна быть двунаправленная (master-master?). То есть, нет никакой «главной» таблицы. Просто все записи, созданные на разных хостах, должны в итоге присутствовать на инстансах PostgreSQL на всех хостах. Скорость репликации не важна. Достаточно, если синхронизация будет происходить периодически. В минуту каждый хост может добавить в таблицу от 0 до ~1000 новых записей. В любой момент сеть может «развалиться» и хосты не смогут видеть друг друга, при этом новые записи будут создаваться. После восстановления сети все новые записи должны засинхронизироваться на всех хостах. Не факт, что все хосты будут работать одновременно. Может 4 хоста работать, а 1 быть выключен. После его включения он должен принять все данные, которые «пропустил» когда был выключен. Может быть и наоборот: работает только 1 хост, остальные выключены. После включения остальных хостов, данные с первого хоста должны перетечь на все остальные. * * * Сейчас я раздумываю, с помощью каких инструментов проще всего решить эту задачу. Насколько я понял, средства репликации, существующие для PostgreSQL 9.1 (тот же slony), умеют делать только master-slave репликацию, да и работа такой репликации в условиях нестабильной сети под большим вопросом. Мне нужно что-то более простое, типа pt-table-sync от Percona, только не для MySQL, а для PostgreSQL. И чтобы оно работало на древних линухах. Перед тем, как я начну писать решение на коленке, я хочу попробовать решить задачу уже готовыми инструментами. Кто что может предложить? Да, сменить дистрибутив не получится, ибо при аттестации/сертификации/лицензиации средства стандартного программного обеспечения зафиксированы
|
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 18:44 , 04-Мрт-20 (1)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintreaMailRu, 18:55 , 04-Мрт-20 (2)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Pahanivo, 19:51 , 04-Мрт-20 (3)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, abi, 00:02 , 05-Мрт-20 (4)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 09:17 , 05-Мрт-20 (10)
> Задача обычная, но требует небольшого планирования. Например, как решать конфликты по уникальным
> полям.А никаких конфликтов нет. Идентификаторы из поля с id могут пересекаться. Это служебное поле для первичной сортировки на одном инстансе. Каждая запись однозначно определяется через UUID, и это значение как раз уникально. Итоговая сортировка объединенных данных должна идти по времени+UUID.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 07:16 , 05-Мрт-20 (8)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 09:19 , 05-Мрт-20 (11)
> Ну да, обычнейшая банальнейшая задача - обеспечить в автоматическом режиме непротиворечивость
> данных, одновременно изменяемых из нескольких источников. На Нобелевку тянет.Я же в топике сказал: "Содержимое записей не меняется". Это несколько меняет дело, не так ли?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 09:29 , 05-Мрт-20 (12)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 09:50 , 05-Мрт-20 (13)
> Нарисуйте лучше обвязку, которая будет делать автопереключение slave-master в зависимости
> от состояния вашей сети при отвале текущего мастера.Значит, на какое-то время в сети появятся два мастера. Один - в отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто из них должен стать главным?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 10:01 , 05-Мрт-20 (14)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 10:12 , 05-Мрт-20 (15)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 10:51 , 05-Мрт-20 (16)
> И вообще - если записи у вас "не меняются", то ответ -
> "а какая разница, кто?" Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что при такой репликации и master заливает на slave новые данные, и slave заливает на master новые данные?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 12:20 , 05-Мрт-20 (17)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 12:28 , 05-Мрт-20 (18)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 12:46 , 05-Мрт-20 (20)
> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным
> образом.
> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом
> недостающие данные, и он раздает их всем состальным.Сеть разделилась. Появилось два мастера. Сеть восстановилась. Выбрали случайно мастером хост1. Этот мастер будет закачивать на хост2 (второй бывший мастер) свои данные. А как хост2 будет закачивать на хост1 свои данные, которые он успел накопить, когда сеть была разделена?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 12:50 , 05-Мрт-20 (22)
> выбираете случайным образом мастер, делаете сравнениеВот тут поподробнее. Как сделать равнение? Между чем и чем? Насколько это будет затратно при сотнях тысяч записей?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 13:01 , 05-Мрт-20 (24)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 14:01 , 05-Мрт-20 (26)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 14:04 , 05-Мрт-20 (27)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 15:41 , 05-Мрт-20 (29)
>>> Насколько это будет затратно при сотнях тысяч записей?
>> секунды надо полагать...
> сравнение надо делать на тех серверах которые слэйвы.... потом обнаруженную разницу -
> залить на мастер - скриптом. и остальные слэйвы уже получат с
> мастера все недостающие данные Сравнение реально сделать SQL-запросом? Или надо делать SELECT всех записей чужих и своих, скриптом сравнивать, и скрпитом же заливать?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 12:34 , 05-Мрт-20 (19)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 12:46 , 05-Мрт-20 (21)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 13:58 , 05-Мрт-20 (25)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 15:43 , 05-Мрт-20 (30)
> имеем 5 уникальных записей в один и тот же момент времени, а
> должна быть одна запись, соответствующая одному моменту времени. Проблема? Не, никаких... Еще раз: у каждой записи есть UUID, в топике об этом сказано.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, odmin, 04:38 , 05-Мрт-20 (5)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, odmin, 04:41 , 05-Мрт-20 (6)
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 08:59 , 05-Мрт-20 (9)
> по простому
> будут две базы, одна postgres на чтение и синхронизируется она стандартными
> средствами репликации stream master slave + wal (в 9.1 это должно быть),
> вторая база это sqlite локальный кеш на запись.
> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную
> базу, назад они вернутся через репликацию.Хех, вы не поверите, но синхронизация на основе пары PostgreSQL + SQLite (для кеша) у меня уже сделано. Но по архитектуре (не моей), в один момент времени назначается только один мастер с PostgreSQL. Это и есть глобальная база. Но сеть может распасться, и в отвалившемся сегменте возникнет еще один мастер. И так до пяти штук. А когда сеть обратно соберется, нужно на всех этих мастерах (т. е. бывших глобальных базах) засинхронизировать данные, чтобы везде получились идентичные таблицы (сортировка в них составная - время+UUID).
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Мимикус Пипикус Онанимус, 10:18 , 08-Мрт-20 (33)
|
Версия для распечатки
