forum.opennet.ru

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

Оглавление

Синхронизация содержимого таблицы для PostgreSQL 9.1, xintrea (ok), 04-Мрт-20, (0) [смотреть все] +1

Проще и надежнее - штатными средствами постгреса Но будет только православный, Аноним (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]

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ообщить модератору

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

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

Партнёры:

Хостинг:

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

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

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ообщить модератору