- Синхронизация содержимого таблицы для PostgreSQL 9.1,
 Аноним, 18:44 , 04-Мрт-20 (1)> Сейчас я раздумываю, с помощью каких инструментов проще всего решить эту задачу.Проще (и надежнее) - штатными средствами постгреса. Но будет только православный master-slave. Вы ТОЧНО хотите master-master?
Ооно вам ДЕЙСТВИТЕЛЬНО надо?
Тогда - только на уровне логической репликации. И неважно, сами вы напишете скрипты синхронизации или воспользуетесь каким-то готовым решением (да, их есть, нет, я их на память не помню, но гугль знает все) - это в любом случае будет уродство из говна и палок, криво работающее и то и дело падающее.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintreaMailRu, 18:55 , 04-Мрт-20 (2)
> или воспользуетесь каким-то готовым решением (да, их есть, нет,
> я их на память не помню, Вопрос был именно в этом.
> но гугль знает все) -
Ничего работающего и подходящего под мои условия я не нашел.
> это в любом случае будет уродство из говна и палок, криво
> работающее и то и дело падающее.
Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем решений?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Pahanivo, 19:51 , 04-Мрт-20 (3)
> Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем
> решений?не совсем понятно, вернее совсем непонятно как в этой "обычной" задаче быть с "PRIMARY KEY id" например ... - Синхронизация содержимого таблицы для 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)
> Ничего работающего и подходящего под мои условия я не нашел.Ищите отсюда - https://wiki.postgresql.org/wiki/Multimaster > Странно, задача ведь самая обычная, неужели до сих пор нет проверенных временем
> решений? Ну да, обычнейшая банальнейшая задача - обеспечить в автоматическом режиме непротиворечивость данных, одновременно изменяемых из нескольких источников. На Нобелевку тянет. А вам подай на халяву решение на второсортном форуме. Да еще и на мертвых дистрибутивах/версиях.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 09:19 , 05-Мрт-20 (11)
> Ну да, обычнейшая банальнейшая задача - обеспечить в автоматическом режиме непротиворечивость
> данных, одновременно изменяемых из нескольких источников. На Нобелевку тянет.Я же в топике сказал: "Содержимое записей не меняется". Это несколько меняет дело, не так ли?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 09:29 , 05-Мрт-20 (12)
> Я же в топике сказал: "Содержимое записей не меняется". Это несколько меняет
> дело, не так ли?Зачем тогда эти экзерсисы с мультимастером?
Нарисуйте лучше обвязку, которая будет делать автопереключение slave-master в зависимости от состояния вашей сети при отвале текущего мастера.
- Синхронизация содержимого таблицы для 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)
>> И вообще - если записи у вас "не меняются", то ответ -
>> "а какая разница, кто?"
> Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что
> при такой репликации и master заливает на slave новые данные, и
> slave заливает на master новые данные?Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным образом.
выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом недостающие данные, и он раздает их всем состальным.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 12:28 , 05-Мрт-20 (18)
>>> И вообще - если записи у вас "не меняются", то ответ -
>>> "а какая разница, кто?"
>> Видимо, я неправильно понимаю механизм репликации master-slave. Вы хотите сказать, что
>> при такой репликации и master заливает на slave новые данные, и
>> slave заливает на master новые данные?
> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным
> образом.
> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом
> недостающие данные, и он раздает их всем остальным.а еще забавные условия с неважно какой скоростью репликации. это означает что например разница в состоянии баз может достигать нескольких месяцев а то и лет... в идеале - их можно вообще никогда не синхронизировать .. ведь скорость синхронизации неважна... она может быть и приближающейся к нулю...
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 12:46 , 05-Мрт-20 (20)
> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным
> образом.
> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом
> недостающие данные, и он раздает их всем состальным.Сеть разделилась. Появилось два мастера. Сеть восстановилась. Выбрали случайно мастером хост1. Этот мастер будет закачивать на хост2 (второй бывший мастер) свои данные. А как хост2 будет закачивать на хост1 свои данные, которые он успел накопить, когда сеть была разделена?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 12:55 , 05-Мрт-20 (23)
>> Он хочет сказать что при ваших требованиях вы можете назначать мастер случайным
>> образом.
>> выбираете случайным образом мастер, делаете сравнение, закачиваете на этот мастер скриптом
>> недостающие данные, и он раздает их всем состальным.
> Сеть разделилась. Появилось два мастера. Два мастера просто так не появятся, пока вы руками (скриптом) не сделаете promote одному из slave. А перед этим нужно будет головой или скриптом принять решение - либо если промотим новый мастер, значит, старый нужно тормознуть. Либо ничего не трогать, ждать пока сеть восстановится.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 12:50 , 05-Мрт-20 (22)
> выбираете случайным образом мастер, делаете сравнениеВот тут поподробнее. Как сделать равнение? Между чем и чем? Насколько это будет затратно при сотнях тысяч записей?
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Аноним, 13:01 , 05-Мрт-20 (24)
>> выбираете случайным образом мастер, делаете сравнение
> Вот тут поподробнее. Как сделать равнение? ЕСЛИ SERVER1.TABLE1.FIELD1 <> SERVER2.TABLE1.FIELD1 ... оставляем либо запись с SERVER1 либо с SERVER2 согласно некоему критерию, например, наиболее позднюю по времени, или наиболее длинную по байтам, или на усмотрение человека-оператора > Между чем и чем? Между данными с мастером и другими серверами > Насколько это
> будет затратно при сотнях тысяч записей? Это будет в конечном итоге не столько затратно, сколько неисполнимо без участия человека.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 14:01 , 05-Мрт-20 (26)
>> выбираете случайным образом мастер, делаете сравнение
> Вот тут поподробнее. Как сделать равнение? Между чем и чем? между сервером который приняли за мастер и собой который слэйв. ну сравнивать очевидно по UUID+таймстамп > Насколько это будет затратно при сотнях тысяч записей? секунды надо полагать...
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 14:04 , 05-Мрт-20 (27)
>>> выбираете случайным образом мастер, делаете сравнение
>> Вот тут поподробнее. Как сделать равнение? Между чем и чем?
> между сервером который приняли за мастер и собой который слэйв.
> ну сравнивать очевидно по UUID+таймстамп
>> Насколько это будет затратно при сотнях тысяч записей?
> секунды надо полагать...сравнение надо делать на тех серверах которые слэйвы.... потом обнаруженную разницу - залить на мастер - скриптом. и остальные слэйвы уже получат с мастера все недостающие данные - Синхронизация содержимого таблицы для 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)
>>> Значит, на какое-то время в сети появятся два мастера. Один - в
>>> отвалившейся части сети, второй - в оставшейся части. Когда сеть обратно
>>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто
>>> из них должен стать главным?
>> Я уже сказал - решить подобную задачу без участия человека - это
>> Нобелевка. Дерзайте.
> Задача автоматического определения "кто будет главным" - решается элементарно.Ну-ну, элементарно. Даже если натянуть на записи некий набор дополнительных условий, всегда остаются нюансы. > что каждая из строк в талице- уникальна (в даже на любом
> сервере) - то с этой стороны вообще никаких проблем. имеем 5 уникальных записей в один и тот же момент времени, а должна быть одна запись, соответствующая одному моменту времени. Проблема? Не, никаких...
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ыы, 13:58 , 05-Мрт-20 (25)
>[оверквотинг удален]
>>>> соберется, возникнет вопрос как засинхрить данные у этих двух мастеров. Кто
>>>> из них должен стать главным?
>>> Я уже сказал - решить подобную задачу без участия человека - это
>>> Нобелевка. Дерзайте.
>> Задача автоматического определения "кто будет главным" - решается элементарно.
> Ну-ну, элементарно. Даже если натянуть на записи некий набор дополнительных условий, всегда
> остаются нюансы.
>> что каждая из строк в талице- уникальна (в даже на любом
>> сервере) - то с этой стороны вообще никаких проблем.
> имеем 5 уникальных записей в один и тот же момент времени, а автор утверждает что таковых нет.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 15:43 , 05-Мрт-20 (30)
> имеем 5 уникальных записей в один и тот же момент времени, а
> должна быть одна запись, соответствующая одному моменту времени. Проблема? Не, никаких... Еще раз: у каждой записи есть UUID, в топике об этом сказано.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, odmin, 04:38 , 05-Мрт-20 (5)
>[оверквотинг удален]
> Скорость репликации не важна. Достаточно, если синхронизация будет происходить периодически.
> В минуту каждый хост может добавить в таблицу от 0 до
> ~1000 новых записей. В любой момент сеть может «развалиться» и хосты
> не смогут видеть друг друга, при этом новые записи будут создаваться.
> После восстановления сети все новые записи должны засинхронизироваться на всех хостах.
> Не факт, что все хосты будут работать одновременно. Может 4 хоста работать,
> а 1 быть выключен. После его включения он должен принять все
> данные, которые «пропустил» когда был выключен. Может быть и наоборот: работает
> только 1 хост, остальные выключены. После включения остальных хостов, данные с
> первого хоста должны перетечь на все остальные.с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому будут две базы, одна postgres на чтение и синхронизируется она стандартными средствами репликации stream master slave + wal (в 9.1 это должно быть),
вторая база это sqlite локальный кеш на запись.
далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную базу, назад они вернутся через репликацию.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, odmin, 04:41 , 05-Мрт-20 (6)
> с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому
> будут две базы, одна postgres на чтение и синхронизируется она стандартными
> средствами репликации stream master slave + wal (в 9.1 это должно
> быть),
> вторая база это sqlite локальный кеш на запись.
> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную
> базу, назад они вернутся через репликацию.с вашей одной таблицей эта задача решается на коленке за неделю, с перерывами на развлечения, и самое главное никаких конфликтов по данным не будет.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, odmin, 04:56 , 05-Мрт-20 (7)
>> с вашими устаревшими версиями - вам нужно менять структуру приложения, по простому
>> будут две базы, одна postgres на чтение и синхронизируется она стандартными
>> средствами репликации stream master slave + wal (в 9.1 это должно
>> быть),
>> вторая база это sqlite локальный кеш на запись.
>> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную
>> базу, назад они вернутся через репликацию.
> с вашей одной таблицей эта задача решается на коленке за неделю, с
> перерывами на развлечения, и самое главное никаких конфликтов по данным не
> будет.это я описал структуру один мастер остальные все slave, но если вам нужна структура где все равны то менять структуру приложения нужно 100%, заводить в базу для каждого хоста свою таблицу, и отдельным процессом их и синхронизировать. Далее в приложении уже запросом вытаскивать ваши данные со всех этих таблиц.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea, 08:59 , 05-Мрт-20 (9)
> по простому
> будут две базы, одна postgres на чтение и синхронизируется она стандартными
> средствами репликации stream master slave + wal (в 9.1 это должно быть),
> вторая база это sqlite локальный кеш на запись.
> далее понятно, дополнительно отдельный процесс на синхронизацию локальных данных в глобальную
> базу, назад они вернутся через репликацию.Хех, вы не поверите, но синхронизация на основе пары PostgreSQL + SQLite (для кеша) у меня уже сделано. Но по архитектуре (не моей), в один момент времени назначается только один мастер с PostgreSQL. Это и есть глобальная база. Но сеть может распасться, и в отвалившемся сегменте возникнет еще один мастер. И так до пяти штук. А когда сеть обратно соберется, нужно на всех этих мастерах (т. е. бывших глобальных базах) засинхронизировать данные, чтобы везде получились идентичные таблицы (сортировка в них составная - время+UUID).
- Синхронизация содержимого таблицы для PostgreSQL 9.1, ACCA, 04:52 , 06-Мрт-20 (31)
> бывших глобальных базах) засинхронизировать данные, чтобы везде получились идентичные
> таблицы (сортировка в них составная - время+UUID).Ага. И у тебя никогда время не уезжало. Про это и говорится в теореме CAP - в общем виде хрен чего у тебя получится. А в частных случаях, бывает что и повезёт.
- Синхронизация содержимого таблицы для PostgreSQL 9.1, Мимикус Пипикус Онанимус, 10:18 , 08-Мрт-20 (33)
>[оверквотинг удален]
> Сейчас я раздумываю, с помощью каких инструментов проще всего решить эту задачу.
> Насколько я понял, средства репликации, существующие для PostgreSQL 9.1 (тот же
> slony), умеют делать только master-slave репликацию, да и работа такой репликации
> в условиях нестабильной сети под большим вопросом.
> Мне нужно что-то более простое, типа pt-table-sync от Percona, только не для
> MySQL, а для PostgreSQL. И чтобы оно работало на древних линухах.
> Перед тем, как я начну писать решение на коленке, я хочу попробовать
> решить задачу уже готовыми инструментами. Кто что может предложить? Да, сменить
> дистрибутив не получится, ибо при аттестации/сертификации/лицензиации средства стандартного
> программного обеспечения зафиксированы Обновиться хотя-бы до 10.x и использовать логическую репликацию таблиц. Работает само и на автомате, правда только в одну сторону. Конфликты изменений в основной таблице и в реплике разруливать вручную. 9.x логическую репликацию не умеет.
|
Версия для распечатки
Синхронизация содержимого таблицы для PostgreSQL 9.1, 
