|
|
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Как я понял есть два варианта реализации синхронного мульти-мастера на postgresql. Postgres-XC и PGCluster. Postgres-XC это обособленная система и в ней нет поддержки триггеров, следовательно имея базу использующую их я не могу построить мульти-мастер. Последний релиз PGCluster аж в 2005 и поддерживает он PostgreSQL8.0.1. Есть ли еще какие-то варианты реализации этой задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 20:14:30 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
http://postgres-xc.sourceforge.net/docs/1_2_beta/plpgsql-overview.html В каком месте он не умеет триггеры?.. Row TRIGGER support. By Amit Khandelar and Ashutosh Bapat - http://postgres-xc.sourceforge.net/docs/1_2_beta/release-xc-1-1.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 20:31:13 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewert, вам не надо этого. какая у вас задача? не бывает "мультимастеров" в общем виде, от слов совсем и нигде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 21:24:50 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Warstone, https://wiki.postgresql.org/wiki/Postgres-XC Triggers/procedures Procedure: Yes Trigger not yet ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 21:35:18 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, Нужно. Задачи на пересечении процссинга терминалов и банковского опердня. Обеспечение безотказной работы, без потери данных и простоя. Пока работаем на потоковой репликации, мастер и два слейва (синхронный и асинхронный), сервера распределены территориально, но не очень нравится необходимость ручного переключения мастер/слейв и последующая работа по возвращению мастера на свое место + будет необходимо выключение сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 21:41:50 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
оно понятно. Вы бы, sterewert, банчок назвали, чтобы случайно не вляпаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 21:50:55 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Охота пуще неволи,, Это, к счастью, не банк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 22:03:39 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewertTrigger not yetИ? А если я на заборе напишу? А я вам показывал официальную доку Пг ХЦ. Ей-то доверять всяко надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 23:15:18 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewert, Что я вам со своей колокольник скажу как человек который изучал потроха Postgresql-XC очень плотно. 1)авторсервера распределены территориально Это 100% и жесткое нет для этой системы... это очень сильносвязанный кластер который КРАЙНЕ чуствителен к сетевым задержкам... и нормально работает только при условии когда они почти нулевые (т.е. только в случае когда весь кластер воткнут в один ВЫДЕЛЕННЫЙ и разумно настроеный коммутатор а не раскиданы непойми где) 2)авторне очень нравится необходимость ручного переключения мастер/слейв Интересно а почему вы думаетет что в PostgreSQL-XC этого нет? Да там можно сделать надежный кластер но все управление в случае падения нод - оно чисто ручное... и в 10 раз сложнее чем просто при потоковой репликации (там реально очень много возни будет). Да и точек отказа сильно побольше. PostrgreSQL-XC это не low maintenance высоконадежное решение а решение для случая когда у вас из-за обьема записи один выделенный мастер сервер уже не справляется в принципе... а делать физический шардинг и переделывать приложение изза этого вам не хочется... в таком случае можно попробовать PostgreSQL-XC и получить еще 5-8 раз запас по производительности сделав кластер на 5-10 нод (да и то не всегда в общем то). Но еще раз про требования очень жесткой связности компонент кластера и отсутствия лагов связи. 3)автор+ будет необходимо выключение сервера Это еще зачем? Всегда все (мастер сервер базы) можно было переключать на реплику не останавливая приложение если сделать по уму (максимум 1-2-5 секунд паузы в обработке клиентских запросов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 01:24:44 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Warstone, Полностью с Вами согласен. Но триггеры реализованы в бета версии, которая к тому же не компилится из за отсутствия preproc.h в исходниках (пробовал 2 дня назад). Тикет от 20-го февраля висит на сайте http://sourceforge.net/p/postgres-xc/mailman/postgres-xc-developers/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 11:49:35 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Спасибо, очень важные комментарии, от человека который с этим сталкивался. Проверять на себе совсем не хотелось бы. По п.3. я наверное не так выразился, в переключении на реплику при падении основного сервера не проблема, время на создание триггер файла не критично. Проблема в том, что если мы работает в режиме 24/7, то не сможем вернуть мастер обратно на тот сервер где он был изначально, до падения, не останавливая текущий мастер (бывший слейв). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 12:00:33 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewertMaxim Boguk, Спасибо, очень важные комментарии, от человека который с этим сталкивался. Проверять на себе совсем не хотелось бы. По п.3. я наверное не так выразился, в переключении на реплику при падении основного сервера не проблема, время на создание триггер файла не критично. Проблема в том, что если мы работает в режиме 24/7, то не сможем вернуть мастер обратно на тот сервер где он был изначально, до падения, не останавливая текущий мастер (бывший слейв). Эээээ????? " то не сможем вернуть мастер обратно на тот сервер где он был изначально, до падения, не останавливая текущий мастер (бывший слейв)" Это почему? Вы кажется что то не так делаете.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 12:59:02 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, "Вы кажется что то не так делаете...." возможно Упрощенно имеем: 1. Изначально Сервер А (мастер) - Сервер Б (слейв) 2. После падения сервера А, сервер Б становится мастер 3. После восстановления работоспособности сервера А, каким образом можно его сделать мастером без остановки сервера Б? Я вижу только вариант: - делать сервер А слейвом по отношении к серверу Б (мастеру) - тригер файлом переключать его в режим мастера - делать сервер Б слейвом по отношению к серверу А (мастеру) Возможно я не понимаю, как можно без промежуточного этапа вернуть все взад, учитывая невозможность остановки мастера и беспрерывной работы в режиме 24/7 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 13:56:05 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewertMaxim Boguk, "Вы кажется что то не так делаете...." возможно Упрощенно имеем: 1. Изначально Сервер А (мастер) - Сервер Б (слейв) 2. После падения сервера А, сервер Б становится мастер 3. После восстановления работоспособности сервера А, каким образом можно его сделать мастером без остановки сервера Б? Я вижу только вариант: - делать сервер А слейвом по отношении к серверу Б (мастеру) - тригер файлом переключать его в режим мастера - делать сервер Б слейвом по отношению к серверу А (мастеру) Возможно я не понимаю, как можно без промежуточного этапа вернуть все взад, учитывая невозможность остановки мастера и беспрерывной работы в режиме 24/7 А где в вашем плане проблема? Он совершенно правильный... и максимальный downtime какой там будет секунд 5 (а если аккуратно сделать то 1 секунда). Т.е. что вам не нравится в той схеме что вы нарисовали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 14:19:15 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewertWarstone, Полностью с Вами согласен. Но триггеры реализованы в бета версии, которая к тому же не компилится из за отсутствия preproc.h в исходниках (пробовал 2 дня назад). Тикет от 20-го февраля висит на сайте http://sourceforge.net/p/postgres-xc/mailman/postgres-xc-developers/ В каком месте Релиз 1.1 - бета версия?.. Ну прочтите ссылочку-то... 1.1 давно релизнулся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 14:24:07 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Maxim BogukА где в вашем плане проблема? Он совершенно правильный... и максимальный downtime какой там будет секунд 5 (а если аккуратно сделать то 1 секунда). Т.е. что вам не нравится в той схеме что вы нарисовали? Как я понял, такой downtime возможен лишь когда для реализации "- делать сервер А слейвом по отношении к серверу Б (мастеру)" не нужно с мастера на слейв полностью копировать кластер, при помощи pg_basebackup, а лишь подгрузить недостающие транзакции (wal файлы). Если это так, то каким образом можно это проделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 15:38:51 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Вопрос снят. Разобрался ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 15:53:47 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Все же, не разобрался. Попробовал реализовать востановление реплики без полной передачи кластера с мастера на слейв. Не работает. Слейв пытается подгрузить не существующий файл с совсем другим таймлайном Код: plsql 1. 2. Вопрос, как можно (если вообще возможно) востановить реплику, после переключения слейва в режим мастера, без полного копирования кластера? sterewertКак я понял, такой downtime возможен лишь когда для реализации "- делать сервер А слейвом по отношении к серверу Б (мастеру)" не нужно с мастера на слейв полностью копировать кластер, при помощи pg_basebackup, а лишь подгрузить недостающие транзакции (wal файлы). Если это так, то каким образом можно это проделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2014, 16:07:53 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewertВсе же, не разобрался. Попробовал реализовать востановление реплики без полной передачи кластера с мастера на слейв. Не работает. Слейв пытается подгрузить не существующий файл с совсем другим таймлайном Код: plsql 1. 2. Вопрос, как можно (если вообще возможно) востановить реплику, после переключения слейва в режим мастера, без полного копирования кластера? sterewertКак я понял, такой downtime возможен лишь когда для реализации "- делать сервер А слейвом по отношении к серверу Б (мастеру)" не нужно с мастера на слейв полностью копировать кластер, при помощи pg_basebackup, а лишь подгрузить недостающие транзакции (wal файлы). Если это так, то каким образом можно это проделать? никак в принципе... а в чем проблема с полным копированием кластера? оно же ничего не стоит кроме сетевого траффика. И не требует остановки мастера или перерыва в обслуживании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2014, 01:48:13 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewertВсе же, не разобрался. Попробовал реализовать востановление реплики без полной передачи кластера с мастера на слейв. Не работает. Слейв пытается подгрузить не существующий файл с совсем другим таймлайном Код: plsql 1. 2. Вопрос, как можно (если вообще возможно) востановить реплику, после переключения слейва в режим мастера, без полного копирования кластера? sterewertКак я понял, такой downtime возможен лишь когда для реализации "- делать сервер А слейвом по отношении к серверу Б (мастеру)" не нужно с мастера на слейв полностью копировать кластер, при помощи pg_basebackup, а лишь подгрузить недостающие транзакции (wal файлы). Если это так, то каким образом можно это проделать?\ хотя... что вы имеете в виду? вам надо старый мастер завести как реплику? или вам надо некоторую третью реплику подключить к новому мастеру? Второе вполне реально... просто ее надо погасить до того как отключать старый мастер (и до того как переводить основную реплику в режим мастера). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2014, 01:50:19 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
[quot sterewert] Код: plsql 1. 2. тут можно включить recovery_target_timeline = 'latest' в recovery.conf и перезапустить stand-by. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2014, 07:13:27 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, "вам надо старый мастер завести как реплику?" да Проблема как раз в сетевом трафике, база достаточно увесистая, а канал между серверами не так широк. В то же время трафик генерируемый при работе, небольшой и пролазит легко в этот канал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2014, 12:24:55 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
[quot daevy]sterewert Код: plsql 1. 2. тут можно включить recovery_target_timeline = 'latest' в recovery.conf и перезапустить stand-by. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Реплика вроде как включилась, не смотря, что отсутствуют некоторые файлы логов (отсутствуют впринципе, а не на слейве). Но данные не реплицируются. sent_location меняется. select sent_location, write_location, flush_location, replay_location from pg_stat_replication Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2014, 13:16:54 |
|
||
|
synchronous multi-master
|
|||
|---|---|---|---|
|
#18+
sterewert"вам надо старый мастер завести как реплику?" да sterewertРеплика вроде как включилась, не смотря, что отсутствуют некоторые файлы логов (отсутствуют впринципе, а не на слейве). Но данные не реплицируются. sent_location меняется. не совсем понял... это вы старый мастер так пытаетесь завести как реплику? или у вас было две реплики, одну вы сделали мастером, а вторую теперь пытаетесь переключить со старого мастера на новый? и еще раз про заведение бывших мастеров в качестве реплик... На данный момент, штатными средствами это сделать невозможно. Есть pg_rewind, но он имхо сыроват и его требуется настраивать до всяких манипулация с переключениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2014, 13:31:15 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38580362&tid=1998804]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
138ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 194ms |
| total: | 421ms |

| 0 / 0 |
