forum.opennet.ru - "Синхронизация содержимого таблицы для PostgreSQL 9.1" (33)

"Синхронизация содержимого таблицы для PostgreSQL 9.1"

Форум WEB технологии (PostgreSQL)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Синхронизация содержимого таблицы для PostgreSQL 9.1"	+1 +/–
Сообщение от xintrea (ok), 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. И чтобы оно работало на древних линухах. Перед тем, как я начну писать решение на коленке, я хочу попробовать решить задачу уже готовыми инструментами. Кто что может предложить? Да, сменить дистрибутив не получится, ибо при аттестации/сертификации/лицензиации средства стандартного программного обеспечения зафиксированы
Ответить \| Правка \| Cообщить модератору

Оглавление

Проще и надежнее - штатными средствами постгреса Но будет только православный, Аноним (1), 18:44 , 04-Мрт-20, (1)

Вопрос был именно в этом Ничего работающего и подходящего под мои условия я не н, xintreaMailRu (?), 18:55 , 04-Мрт-20, (2)

не совсем понятно, вернее совсем непонятно как в этой обычной задаче быть с P, Pahanivo (ok), 19:51 , 04-Мрт-20, (3)
Задача обычная, но требует небольшого планирования Например, как решать конфлик, abi (?), 00:02 , 05-Мрт-20, (4)

А никаких конфликтов нет Идентификаторы из поля с id могут пересекаться Это сл, xintrea (ok), 09:17 , 05-Мрт-20, (10)

Ищите отсюда - https wiki postgresql org wiki MultimasterНу да, обычнейшая бан, Аноним (8), 07:16 , 05-Мрт-20, (8)

Я же в топике сказал Содержимое записей не меняется Это несколько меняет дел, xintrea (ok), 09:19 , 05-Мрт-20, (11)

Зачем тогда эти экзерсисы с мультимастером Нарисуйте лучше обвязку, которая буде, Аноним (8), 09:29 , 05-Мрт-20, (12)

Значит, на какое-то время в сети появятся два мастера Один - в отвалившейся час, xintrea (ok), 09:50 , 05-Мрт-20, (13)

Я уже сказал - решить подобную задачу без участия человека - это Нобелевка Дерз, Аноним (8), 10:01 , 05-Мрт-20, (14)

И вообще - если записи у вас не меняются , то ответ - а какая разница, кто , Аноним (8), 10:12 , 05-Мрт-20, (15)

Видимо, я неправильно понимаю механизм репликации master-slave Вы хотите сказат, xintrea (ok), 10:51 , 05-Мрт-20, (16)

Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным , ыы (?), 12:20 , 05-Мрт-20, (17)

а еще забавные условия с неважно какой скоростью репликации это означает что нап, ыы (?), 12:28 , 05-Мрт-20, (18)
Сеть разделилась Появилось два мастера Сеть восстановилась Выбрали случайно м, xintrea (ok), 12:46 , 05-Мрт-20, (20)

Два мастера просто так не появятся, пока вы руками скриптом не сделаете promot, Аноним (8), 12:55 , 05-Мрт-20, (23)

Вот тут поподробнее Как сделать равнение Между чем и чем Насколько это будет , xintrea (ok), 12:50 , 05-Мрт-20, (22)

ЕСЛИ SERVER1 TABLE1 FIELD1 SERVER2 TABLE1 FIELD1 оставляем либо запись с, Аноним (8), 13:01 , 05-Мрт-20, (24)
между сервером который приняли за мастер и собой который слэйв ну сравнивать оче, ыы (?), 14:01 , 05-Мрт-20, (26)
сравнение надо делать на тех серверах которые слэйвы потом обнаруженную разн, ыы (?), 14:04 , 05-Мрт-20, (27)
Сравнение реально сделать SQL-запросом Или надо делать SELECT всех записей чужи, xintrea (ok), 15:41 , 05-Мрт-20, (29)

Задача автоматического определения кто будет главным - решается элементарно а, ыы (?), 12:34 , 05-Мрт-20, (19)

Ну-ну, элементарно Даже если натянуть на записи некий набор дополнительных усло, Аноним (8), 12:46 , 05-Мрт-20, (21)

gt оверквотинг удален автор утверждает что таковых нет , ыы (?), 13:58 , 05-Мрт-20, (25)

Пусть афтырь сам с собой разберется, что у него есть, и чего нет Записи не меняю, Аноним (8), 14:14 , 05-Мрт-20, (28)

Еще раз у каждой записи есть UUID, в топике об этом сказано , xintrea (ok), 15:43 , 05-Мрт-20, (30)

gt оверквотинг удален с вашими устаревшими версиями - вам нужно менять структу, odmin (??), 04:38 , 05-Мрт-20, (5)

с вашей одной таблицей эта задача решается на коленке за неделю, с перерывами на, odmin (??), 04:41 , 05-Мрт-20, (6)

это я описал структуру один мастер остальные все slave, но если вам нужна структ, odmin (??), 04:56 , 05-Мрт-20, (7)

Хех, вы не поверите, но синхронизация на основе пары PostgreSQL SQLite для ке, xintrea (ok), 08:59 , 05-Мрт-20, (9)

Ага И у тебя никогда время не уезжало Про это и говорится в теореме CAP - в общ, ACCA (ok), 04:52 , 06-Мрт-20, (31)

Ыыы, 5 к 1, что еще в Local Time Zone , Аноним (32), 08:33 , 06-Мрт-20, (32)

gt оверквотинг удален Обновиться хотя-бы до 10 x и использовать логическую реп, Мимикус Пипикус Онанимус (?), 10:18 , 08-Мрт-20, (33)

Сообщения [Сортировка по времени | RSS]

1. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (1), 04-Мрт-20, 18:44

> Сейчас я раздумываю, с помощью каких инструментов проще всего решить эту задачу.
Проще (и надежнее) - штатными средствами постгреса. Но будет только православный master-slave.
Вы ТОЧНО хотите master-master?
Ооно вам ДЕЙСТВИТЕЛЬНО надо?
Тогда - только на уровне логической репликации. И неважно, сами вы напишете скрипты синхронизации или воспользуетесь каким-то готовым решением (да, их есть, нет, я их на память не помню, но гугль знает все) - это в любом случае будет уродство из говна и палок, криво работающее и то и дело падающее.

Ответить | Правка | Наверх | Cообщить модератору

2. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintreaMailRu (?), 04-Мрт-20, 18:55

> или воспользуетесь каким-то готовым решением (да, их есть, нет,
> я их на память не помню,
Вопрос был именно в этом.

> но гугль знает все) -
Ничего работающего и подходящего под мои условия я не нашел.

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

Ответить | Правка | Наверх | Cообщить модератору

3. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Pahanivo (ok), 04-Мрт-20, 19:51

> Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем
> решений?
не совсем понятно, вернее совсем непонятно как в этой "обычной" задаче быть с "PRIMARY KEY id" например ...

Ответить | Правка | Наверх | Cообщить модератору

4. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от abi (?), 05-Мрт-20, 00:02

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

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

10. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 09:17

> Задача обычная, но требует небольшого планирования. Например, как решать конфликты по уникальным
> полям.
А никаких конфликтов нет. Идентификаторы из поля с id могут пересекаться. Это служебное поле для первичной сортировки на одном инстансе. Каждая запись однозначно определяется через UUID, и это значение как раз уникально. Итоговая сортировка объединенных данных должна идти по времени+UUID.

Ответить | Правка | Наверх | Cообщить модератору

8. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 07:16

> Ничего работающего и подходящего под мои условия я не нашел.
Ищите отсюда - https://wiki.postgresql.org/wiki/Multimaster
> Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем
> решений?
Ну да, обычнейшая банальнейшая задача - обеспечить в автоматическом режиме непротиворечивость данных, одновременно изменяемых из нескольких источников. На Нобелевку тянет. А вам подай на халяву решение на второсортном форуме. Да еще и на мертвых дистрибутивах/версиях.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

11. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 09:19

> Ну да, обычнейшая банальнейшая задача - обеспечить в автоматическом режиме непротиворечивость
> данных, одновременно изменяемых из нескольких источников. На Нобелевку тянет.
Я же в топике сказал: "Содержимое записей не меняется". Это несколько меняет дело, не так ли?

Ответить | Правка | Наверх | Cообщить модератору

12. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 09:29

> Я же в топике сказал: "Содержимое записей не меняется". Это несколько меняет
> дело, не так ли?
Зачем тогда эти экзерсисы с мультимастером?
Нарисуйте лучше обвязку, которая будет делать автопереключение slave-master в зависимости от состояния вашей сети при отвале текущего мастера.

Ответить | Правка | Наверх | Cообщить модератору

13. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 09:50

> Нарисуйте лучше обвязку, которая будет делать автопереключение slave-master в зависимости
> от состояния вашей сети при отвале текущего мастера.
Значит, на какое-то время в сети появятся два мастера. Один - в отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто из них должен стать главным?

Ответить | Правка | Наверх | Cообщить модератору

14. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 10:01

> Значит, на какое-то время в сети появятся два мастера. Один - в
> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно
> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто
> из них должен стать главным?
Я уже сказал - решить подобную задачу без участия человека - это Нобелевка. Дерзайте.

Ответить | Правка | Наверх | Cообщить модератору

15. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 10:12

>> Значит, на какое-то время в сети появятся два мастера. Один - в
>> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно
>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто
>> из них должен стать главным?
И вообще - если записи у вас "не меняются", то ответ - "а какая разница, кто?"

Ответить | Правка | Наверх | Cообщить модератору

16. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 10:51

> И вообще - если записи у вас "не меняются", то ответ -
> "а какая разница, кто?"
Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что при такой репликации и master заливает на slave новые данные, и slave заливает на master новые данные?

Ответить | Правка | Наверх | Cообщить модератору

17. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от ыы (?), 05-Мрт-20, 12:20

>> И вообще - если записи у вас "не меняются", то ответ -
>> "а какая разница, кто?"
> Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что
> при такой репликации и master заливает на slave новые данные, и
> slave заливает на master новые данные?
Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным образом.
выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом недостающие данные, и он раздает их всем состальным.

Ответить | Правка | Наверх | Cообщить модератору

18. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от ыы (?), 05-Мрт-20, 12:28

>>> И вообще - если записи у вас "не меняются", то ответ -
>>> "а какая разница, кто?"
>> Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что
>> при такой репликации и master заливает на slave новые данные, и
>> slave заливает на master новые данные?
> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным
> образом.
> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом
> недостающие данные, и он раздает их всем остальным.
а еще забавные условия с неважно какой скоростью репликации.
это означает что например разница в состоянии баз может достигать нескольких месяцев а то и лет... в идеале - их можно вообще никогда не синхронизировать .. ведь скорость синхронизации неважна... она может быть и приближающейся к нулю...

Ответить | Правка | Наверх | Cообщить модератору

20. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 12:46

> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным
> образом.
> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом
> недостающие данные, и он раздает их всем состальным.
Сеть разделилась. Появилось два мастера. Сеть восстановилась. Выбрали случайно мастером хост1. Этот мастер будет закачивать на хост2 (второй бывший мастер) свои данные. А как хост2 будет закачивать на хост1 свои данные, которые он успел накопить, когда сеть была разделена?

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

23. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 12:55

>> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным
>> образом.
>> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом
>> недостающие данные, и он раздает их всем состальным.
> Сеть разделилась. Появилось два мастера.
Два мастера просто так не появятся, пока вы руками (скриптом) не сделаете promote одному из slave. А перед этим нужно будет головой или скриптом принять решение - либо если промотим новый мастер, значит, старый нужно тормознуть. Либо ничего не трогать, ждать пока сеть восстановится.

Ответить | Правка | Наверх | Cообщить модератору

22. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 12:50

> выбираете случайным образом мастер, делаете сравнение
Вот тут поподробнее. Как сделать равнение? Между чем и чем? Насколько это будет затратно при сотнях тысяч записей?

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

24. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 13:01

>> выбираете случайным образом мастер, делаете сравнение
> Вот тут поподробнее. Как сделать равнение?
ЕСЛИ SERVER1.TABLE1.FIELD1 <> SERVER2.TABLE1.FIELD1 ... оставляем либо запись с SERVER1 либо с SERVER2 согласно некоему критерию, например, наиболее позднюю по времени, или наиболее длинную по байтам, или на усмотрение человека-оператора
> Между чем и чем?
Между данными с мастером и другими серверами
> Насколько это
> будет затратно при сотнях тысяч записей?
Это будет в конечном итоге не столько затратно, сколько неисполнимо без участия человека.

Ответить | Правка | Наверх | Cообщить модератору

26. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от ыы (?), 05-Мрт-20, 14:01

>> выбираете случайным образом мастер, делаете сравнение
> Вот тут поподробнее. Как сделать равнение? Между чем и чем?
между сервером который приняли за мастер и собой который слэйв.
ну сравнивать очевидно по UUID+таймстамп
> Насколько это  будет затратно при сотнях тысяч записей?
секунды надо полагать...

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

27. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от ыы (?), 05-Мрт-20, 14:04

>>> выбираете случайным образом мастер, делаете сравнение
>> Вот тут поподробнее. Как сделать равнение? Между чем и чем?
> между сервером который приняли за мастер и собой который слэйв.
> ну сравнивать очевидно по UUID+таймстамп
>> Насколько это  будет затратно при сотнях тысяч записей?
> секунды надо полагать...
сравнение надо делать на тех серверах которые слэйвы.... потом обнаруженную разницу - залить на мастер - скриптом. и остальные слэйвы уже получат с мастера все недостающие данные

Ответить | Правка | Наверх | Cообщить модератору

29. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 15:41

>>> Насколько это  будет затратно при сотнях тысяч записей?
>> секунды надо полагать...
> сравнение надо делать на тех серверах которые слэйвы.... потом обнаруженную разницу -
> залить на мастер - скриптом. и остальные слэйвы уже получат с
> мастера все недостающие данные
Сравнение реально сделать SQL-запросом? Или надо делать SELECT всех записей чужих и своих, скриптом сравнивать, и скрпитом же заливать?

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

19. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от ыы (?), 05-Мрт-20, 12:34

>> Значит, на какое-то время в сети появятся два мастера. Один - в
>> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно
>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто
>> из них должен стать главным?
> Я уже сказал - решить подобную задачу без участия человека - это
> Нобелевка. Дерзайте.
Задача автоматического определения "кто будет главным" - решается элементарно. а учитывая что каждая из строк в талице- уникальна (в даже на любом сервере) - то с этой стороны вообще никаких проблем. задача только в перекачке данных.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

21. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 12:46

>>> Значит, на какое-то время в сети появятся два мастера. Один - в
>>> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно
>>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто
>>> из них должен стать главным?
>> Я уже сказал - решить подобную задачу без участия человека - это
>> Нобелевка. Дерзайте.
> Задача автоматического определения "кто будет главным" - решается элементарно.
Ну-ну, элементарно. Даже если натянуть на записи некий набор дополнительных условий, всегда остаются нюансы.
> что каждая из строк в талице- уникальна (в даже на любом
> сервере) - то с этой стороны вообще никаких проблем.
имеем 5 уникальных записей в один и тот же момент времени, а должна быть одна запись, соответствующая одному моменту времени. Проблема? Не, никаких...

Ответить | Правка | Наверх | Cообщить модератору

25. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от ыы (?), 05-Мрт-20, 13:58

>[оверквотинг удален]
>>>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто
>>>> из них должен стать главным?
>>> Я уже сказал - решить подобную задачу без участия человека - это
>>> Нобелевка. Дерзайте.
>> Задача автоматического определения "кто будет главным" - решается элементарно.
> Ну-ну, элементарно. Даже если натянуть на записи некий набор дополнительных условий, всегда
> остаются нюансы.
>> что каждая из строк в талице- уникальна (в даже на любом
>> сервере) - то с этой стороны вообще никаких проблем.
> имеем 5 уникальных записей в один и тот же момент времени, а
автор утверждает что таковых нет.

Ответить | Правка | Наверх | Cообщить модератору

28. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (8), 05-Мрт-20, 14:14

> автор утверждает что таковых нет.
Пусть афтырь сам с собой разберется, что у него есть, и чего нет.
Записи не меняются, но при этом надо мультимастер. Видимо, "чтобы было".

Ответить | Правка | Наверх | Cообщить модератору

30. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 15:43

> имеем 5 уникальных записей в один и тот же момент времени, а
> должна быть одна запись, соответствующая одному моменту времени. Проблема? Не, никаких...
Еще раз: у каждой записи есть UUID, в топике об этом сказано.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

5. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от odmin (??), 05-Мрт-20, 04:38

>[оверквотинг удален]
> Скорость репликации не важна. Достаточно, если синхронизация будет происходить периодически.
> В минуту каждый хост может добавить в таблицу от 0 до
> ~1000 новых записей. В любой момент сеть может «развалиться» и хосты
> не смогут видеть друг друга, при этом новые записи будут создаваться.
> После восстановления сети все новые записи должны засинхронизироваться на всех хостах.
> Не факт, что все хосты будут работать одновременно. Может 4 хоста работать,
> а 1 быть выключен. После его включения он должен принять все
> данные, которые «пропустил» когда был выключен. Может быть и наоборот: работает
> только 1 хост, остальные выключены. После включения остальных хостов, данные с
> первого хоста должны перетечь на все остальные.
с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому будут две базы, одна postgres на чтение и синхронизируется она стандартными средствами репликации stream master slave + wal (в 9.1 это должно быть),
вторая база это sqlite локальный кеш на запись.
далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную базу, назад они вернутся через репликацию.

Ответить | Правка | Наверх | Cообщить модератору

6. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от odmin (??), 05-Мрт-20, 04:41

> с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому
> будут две базы, одна postgres на чтение и синхронизируется она стандартными
> средствами репликации stream master slave + wal (в 9.1 это должно
> быть),
> вторая база это sqlite локальный кеш на запись.
> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную
> базу, назад они вернутся через репликацию.
с вашей одной таблицей эта задача решается на коленке за неделю, с перерывами на развлечения, и самое главное никаких конфликтов по данным не будет.

Ответить | Правка | Наверх | Cообщить модератору

7. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от odmin (??), 05-Мрт-20, 04:56

>> с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому
>> будут две базы, одна postgres на чтение и синхронизируется она стандартными
>> средствами репликации stream master slave + wal (в 9.1 это должно
>> быть),
>> вторая база это sqlite локальный кеш на запись.
>> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную
>> базу, назад они вернутся через репликацию.
> с вашей одной таблицей эта задача решается на коленке за неделю, с
> перерывами на развлечения, и самое главное никаких конфликтов по данным не
> будет.
это я описал структуру один мастер остальные все slave, но если вам нужна структура где все равны то менять структуру приложения нужно 100%, заводить в базу для каждого хоста свою таблицу, и отдельным процессом их и синхронизировать. Далее в приложении уже запросом вытаскивать ваши данные со всех этих таблиц.

Ответить | Правка | Наверх | Cообщить модератору

9. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от xintrea (ok), 05-Мрт-20, 08:59

> по простому
> будут две базы, одна postgres на чтение и синхронизируется она стандартными
> средствами репликации stream master slave + wal (в 9.1 это должно быть),
> вторая база это sqlite локальный кеш на запись.
> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную
> базу, назад они вернутся через репликацию.
Хех, вы не поверите, но синхронизация на основе пары PostgreSQL + SQLite (для кеша) у меня уже сделано. Но по архитектуре (не моей), в один момент времени назначается только один мастер с PostgreSQL. Это и есть глобальная база. Но сеть может распасться, и в отвалившемся сегменте возникнет еще один мастер. И так до пяти штук. А когда сеть обратно соберется, нужно на всех этих мастерах (т. е. бывших глобальных базах) засинхронизировать данные, чтобы везде получились идентичные таблицы (сортировка в них составная - время+UUID).

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

31. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от ACCA (ok), 06-Мрт-20, 04:52

> бывших глобальных базах) засинхронизировать данные, чтобы везде получились идентичные
> таблицы (сортировка в них составная - время+UUID).
Ага. И у тебя никогда время не уезжало.
Про это и говорится в теореме CAP - в общем виде хрен чего у тебя получится. А в частных случаях, бывает что и повезёт.

Ответить | Правка | Наверх | Cообщить модератору

32. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Аноним (32), 06-Мрт-20, 08:33

> Ага. И у тебя никогда время не уезжало.
Ыыы, 5 к 1, что еще в Local Time Zone...

Ответить | Правка | Наверх | Cообщить модератору

33. "Синхронизация содержимого таблицы для PostgreSQL 9.1" +/–

Сообщение от Мимикус Пипикус Онанимус (?), 08-Мрт-20, 10:18

>[оверквотинг удален]
> Сейчас я раздумываю, с помощью каких инструментов проще всего решить эту задачу.
> Насколько я понял, средства репликации, существующие для PostgreSQL 9.1 (тот же
> slony), умеют делать только master-slave репликацию, да и работа такой репликации
> в условиях нестабильной сети под большим вопросом.
> Мне нужно что-то более простое, типа pt-table-sync от Percona, только не для
> MySQL, а для PostgreSQL. И чтобы оно работало на древних линухах.
> Перед тем, как я начну писать решение на коленке, я хочу попробовать
> решить задачу уже готовыми инструментами. Кто что может предложить? Да, сменить
> дистрибутив не получится, ибо при аттестации/сертификации/лицензиации средства стандартного
> программного обеспечения зафиксированы
Обновиться хотя-бы до 10.x и использовать логическую репликацию таблиц. Работает само и на автомате, правда только в одну сторону. Конфликты изменений в основной таблице и в реплике разруливать вручную. 9.x логическую репликацию не умеет.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
Сообщение от Аноним (1), 04-Мрт-20, 18:44
> Сейчас я раздумываю, с помощью каких инструментов проще всего решить эту задачу. Проще (и надежнее) - штатными средствами постгреса. Но будет только православный master-slave. Вы ТОЧНО хотите master-master? Ооно вам ДЕЙСТВИТЕЛЬНО надо? Тогда - только на уровне логической репликации. И неважно, сами вы напишете скрипты синхронизации или воспользуетесь каким-то готовым решением (да, их есть, нет, я их на память не помню, но гугль знает все) - это в любом случае будет уродство из говна и палок, криво работающее и то и дело падающее.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintreaMailRu (?), 04-Мрт-20, 18:55
	> или воспользуетесь каким-то готовым решением (да, их есть, нет, > я их на память не помню, Вопрос был именно в этом. > но гугль знает все) - Ничего работающего и подходящего под мои условия я не нашел. > это в любом случае будет уродство из говна и палок, криво > работающее и то и дело падающее. Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем решений?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Pahanivo (ok), 04-Мрт-20, 19:51
	> Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем > решений? не совсем понятно, вернее совсем непонятно как в этой "обычной" задаче быть с "PRIMARY KEY id" например ...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от abi (?), 05-Мрт-20, 00:02
	> Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем > решений? Задача обычная, но требует небольшого планирования. Например, как решать конфликты по уникальным полям.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	10. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 09:17
	> Задача обычная, но требует небольшого планирования. Например, как решать конфликты по уникальным > полям. А никаких конфликтов нет. Идентификаторы из поля с id могут пересекаться. Это служебное поле для первичной сортировки на одном инстансе. Каждая запись однозначно определяется через UUID, и это значение как раз уникально. Итоговая сортировка объединенных данных должна идти по времени+UUID.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 07:16
	> Ничего работающего и подходящего под мои условия я не нашел. Ищите отсюда - https://wiki.postgresql.org/wiki/Multimaster > Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем > решений? Ну да, обычнейшая банальнейшая задача - обеспечить в автоматическом режиме непротиворечивость данных, одновременно изменяемых из нескольких источников. На Нобелевку тянет. А вам подай на халяву решение на второсортном форуме. Да еще и на мертвых дистрибутивах/версиях.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	11. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 09:19
	> Ну да, обычнейшая банальнейшая задача - обеспечить в автоматическом режиме непротиворечивость > данных, одновременно изменяемых из нескольких источников. На Нобелевку тянет. Я же в топике сказал: "Содержимое записей не меняется". Это несколько меняет дело, не так ли?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 09:29
	> Я же в топике сказал: "Содержимое записей не меняется". Это несколько меняет > дело, не так ли? Зачем тогда эти экзерсисы с мультимастером? Нарисуйте лучше обвязку, которая будет делать автопереключение slave-master в зависимости от состояния вашей сети при отвале текущего мастера.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 09:50
	> Нарисуйте лучше обвязку, которая будет делать автопереключение slave-master в зависимости > от состояния вашей сети при отвале текущего мастера. Значит, на какое-то время в сети появятся два мастера. Один - в отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто из них должен стать главным?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 10:01
	> Значит, на какое-то время в сети появятся два мастера. Один - в > отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно > соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто > из них должен стать главным? Я уже сказал - решить подобную задачу без участия человека - это Нобелевка. Дерзайте.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 10:12
	>> Значит, на какое-то время в сети появятся два мастера. Один - в >> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно >> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто >> из них должен стать главным? И вообще - если записи у вас "не меняются", то ответ - "а какая разница, кто?"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 10:51
	> И вообще - если записи у вас "не меняются", то ответ - > "а какая разница, кто?" Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что при такой репликации и master заливает на slave новые данные, и slave заливает на master новые данные?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от ыы (?), 05-Мрт-20, 12:20
	>> И вообще - если записи у вас "не меняются", то ответ - >> "а какая разница, кто?" > Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что > при такой репликации и master заливает на slave новые данные, и > slave заливает на master новые данные? Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным образом. выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом недостающие данные, и он раздает их всем состальным.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от ыы (?), 05-Мрт-20, 12:28
	>>> И вообще - если записи у вас "не меняются", то ответ - >>> "а какая разница, кто?" >> Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что >> при такой репликации и master заливает на slave новые данные, и >> slave заливает на master новые данные? > Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным > образом. > выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом > недостающие данные, и он раздает их всем остальным. а еще забавные условия с неважно какой скоростью репликации. это означает что например разница в состоянии баз может достигать нескольких месяцев а то и лет... в идеале - их можно вообще никогда не синхронизировать .. ведь скорость синхронизации неважна... она может быть и приближающейся к нулю...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 12:46
	> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным > образом. > выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом > недостающие данные, и он раздает их всем состальным. Сеть разделилась. Появилось два мастера. Сеть восстановилась. Выбрали случайно мастером хост1. Этот мастер будет закачивать на хост2 (второй бывший мастер) свои данные. А как хост2 будет закачивать на хост1 свои данные, которые он успел накопить, когда сеть была разделена?
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	23. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 12:55
	>> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным >> образом. >> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом >> недостающие данные, и он раздает их всем состальным. > Сеть разделилась. Появилось два мастера. Два мастера просто так не появятся, пока вы руками (скриптом) не сделаете promote одному из slave. А перед этим нужно будет головой или скриптом принять решение - либо если промотим новый мастер, значит, старый нужно тормознуть. Либо ничего не трогать, ждать пока сеть восстановится.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 12:50
	> выбираете случайным образом мастер, делаете сравнение Вот тут поподробнее. Как сделать равнение? Между чем и чем? Насколько это будет затратно при сотнях тысяч записей?
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	24. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 13:01
	>> выбираете случайным образом мастер, делаете сравнение > Вот тут поподробнее. Как сделать равнение? ЕСЛИ SERVER1.TABLE1.FIELD1 <> SERVER2.TABLE1.FIELD1 ... оставляем либо запись с SERVER1 либо с SERVER2 согласно некоему критерию, например, наиболее позднюю по времени, или наиболее длинную по байтам, или на усмотрение человека-оператора > Между чем и чем? Между данными с мастером и другими серверами > Насколько это > будет затратно при сотнях тысяч записей? Это будет в конечном итоге не столько затратно, сколько неисполнимо без участия человека.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от ыы (?), 05-Мрт-20, 14:01
	>> выбираете случайным образом мастер, делаете сравнение > Вот тут поподробнее. Как сделать равнение? Между чем и чем? между сервером который приняли за мастер и собой который слэйв. ну сравнивать очевидно по UUID+таймстамп > Насколько это будет затратно при сотнях тысяч записей? секунды надо полагать...
	Ответить \| Правка \| К родителю #22 \| Наверх \| Cообщить модератору


	27. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от ыы (?), 05-Мрт-20, 14:04
	>>> выбираете случайным образом мастер, делаете сравнение >> Вот тут поподробнее. Как сделать равнение? Между чем и чем? > между сервером который приняли за мастер и собой который слэйв. > ну сравнивать очевидно по UUID+таймстамп >> Насколько это будет затратно при сотнях тысяч записей? > секунды надо полагать... сравнение надо делать на тех серверах которые слэйвы.... потом обнаруженную разницу - залить на мастер - скриптом. и остальные слэйвы уже получат с мастера все недостающие данные
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 15:41
	>>> Насколько это будет затратно при сотнях тысяч записей? >> секунды надо полагать... > сравнение надо делать на тех серверах которые слэйвы.... потом обнаруженную разницу - > залить на мастер - скриптом. и остальные слэйвы уже получат с > мастера все недостающие данные Сравнение реально сделать SQL-запросом? Или надо делать SELECT всех записей чужих и своих, скриптом сравнивать, и скрпитом же заливать?
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	19. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от ыы (?), 05-Мрт-20, 12:34
	>> Значит, на какое-то время в сети появятся два мастера. Один - в >> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно >> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто >> из них должен стать главным? > Я уже сказал - решить подобную задачу без участия человека - это > Нобелевка. Дерзайте. Задача автоматического определения "кто будет главным" - решается элементарно. а учитывая что каждая из строк в талице- уникальна (в даже на любом сервере) - то с этой стороны вообще никаких проблем. задача только в перекачке данных.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	21. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 12:46
	>>> Значит, на какое-то время в сети появятся два мастера. Один - в >>> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно >>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто >>> из них должен стать главным? >> Я уже сказал - решить подобную задачу без участия человека - это >> Нобелевка. Дерзайте. > Задача автоматического определения "кто будет главным" - решается элементарно. Ну-ну, элементарно. Даже если натянуть на записи некий набор дополнительных условий, всегда остаются нюансы. > что каждая из строк в талице- уникальна (в даже на любом > сервере) - то с этой стороны вообще никаких проблем. имеем 5 уникальных записей в один и тот же момент времени, а должна быть одна запись, соответствующая одному моменту времени. Проблема? Не, никаких...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от ыы (?), 05-Мрт-20, 13:58
	>[оверквотинг удален] >>>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто >>>> из них должен стать главным? >>> Я уже сказал - решить подобную задачу без участия человека - это >>> Нобелевка. Дерзайте. >> Задача автоматического определения "кто будет главным" - решается элементарно. > Ну-ну, элементарно. Даже если натянуть на записи некий набор дополнительных условий, всегда > остаются нюансы. >> что каждая из строк в талице- уникальна (в даже на любом >> сервере) - то с этой стороны вообще никаких проблем. > имеем 5 уникальных записей в один и тот же момент времени, а автор утверждает что таковых нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от Аноним (8), 05-Мрт-20, 14:14
	> автор утверждает что таковых нет. Пусть афтырь сам с собой разберется, что у него есть, и чего нет. Записи не меняются, но при этом надо мультимастер. Видимо, "чтобы было".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 15:43
	> имеем 5 уникальных записей в один и тот же момент времени, а > должна быть одна запись, соответствующая одному моменту времени. Проблема? Не, никаких... Еще раз: у каждой записи есть UUID, в топике об этом сказано.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору

5. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
Сообщение от odmin (??), 05-Мрт-20, 04:38
>[оверквотинг удален] > Скорость репликации не важна. Достаточно, если синхронизация будет происходить периодически. > В минуту каждый хост может добавить в таблицу от 0 до > ~1000 новых записей. В любой момент сеть может «развалиться» и хосты > не смогут видеть друг друга, при этом новые записи будут создаваться. > После восстановления сети все новые записи должны засинхронизироваться на всех хостах. > Не факт, что все хосты будут работать одновременно. Может 4 хоста работать, > а 1 быть выключен. После его включения он должен принять все > данные, которые «пропустил» когда был выключен. Может быть и наоборот: работает > только 1 хост, остальные выключены. После включения остальных хостов, данные с > первого хоста должны перетечь на все остальные. с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому будут две базы, одна postgres на чтение и синхронизируется она стандартными средствами репликации stream master slave + wal (в 9.1 это должно быть), вторая база это sqlite локальный кеш на запись. далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную базу, назад они вернутся через репликацию.
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от odmin (??), 05-Мрт-20, 04:41
	> с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому > будут две базы, одна postgres на чтение и синхронизируется она стандартными > средствами репликации stream master slave + wal (в 9.1 это должно > быть), > вторая база это sqlite локальный кеш на запись. > далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную > базу, назад они вернутся через репликацию. с вашей одной таблицей эта задача решается на коленке за неделю, с перерывами на развлечения, и самое главное никаких конфликтов по данным не будет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от odmin (??), 05-Мрт-20, 04:56
	>> с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому >> будут две базы, одна postgres на чтение и синхронизируется она стандартными >> средствами репликации stream master slave + wal (в 9.1 это должно >> быть), >> вторая база это sqlite локальный кеш на запись. >> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную >> базу, назад они вернутся через репликацию. > с вашей одной таблицей эта задача решается на коленке за неделю, с > перерывами на развлечения, и самое главное никаких конфликтов по данным не > будет. это я описал структуру один мастер остальные все slave, но если вам нужна структура где все равны то менять структуру приложения нужно 100%, заводить в базу для каждого хоста свою таблицу, и отдельным процессом их и синхронизировать. Далее в приложении уже запросом вытаскивать ваши данные со всех этих таблиц.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Синхронизация содержимого таблицы для PostgreSQL 9.1"	+/–
	Сообщение от xintrea (ok), 05-Мрт-20, 08:59
	> по простому > будут две базы, одна postgres на чтение и синхронизируется она стандартными > средствами репликации stream master slave + wal (в 9.1 это должно быть), > вторая база это sqlite локальный кеш на запись. > далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную > базу, назад они вернутся через репликацию. Хех, вы не поверите, но синхронизация на основе пары PostgreSQL + SQLite (для кеша) у меня уже сделано. Но по архитектуре (не моей), в один момент времени назначается только один мастер с PostgreSQL. Это и есть глобальная база. Но сеть может распасться, и в отвалившемся сегменте возникнет еще один мастер. И так до пяти штук. А когда сеть обратно соберется, нужно на всех этих мастерах (т. е. бывших глобальных базах) засинхронизировать данные, чтобы везде получились идентичные таблицы (сортировка в них составная - время+UUID).
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору