Comments 29
В принципе интересно, но как добавить репликацию к уже имеющейся и пусть не сильно большой, но уже прилично весящей базе? Экспортировать текущую, создавать новую реплицируемую и импортировать данные туда? Или можно добавить репликацию к имеющейся рабочей базе «на лету» (естественно с требующейся по ходе дела остановкой, если нужно).
Да, можно добавить репликацию к имеющейся базе. Для этого необходимо модифицировать код файла insert_sample.sql, создав в таблицах Symmetric DS (начинающизся на sym_) нужные записи.
Особенность Symmetric DS такова, что он может реплицировать не всю базу подряд, а только некоторые ее таблицы. Например, у нас есть branch office и менеджер по продажам вносит в локальную базу нового клиента. Эта информация о клиенте синхронизируется с главной базой в headquarters и становится после этого доступна для остальных branch offices.
Особенность Symmetric DS такова, что он может реплицировать не всю базу подряд, а только некоторые ее таблицы. Например, у нас есть branch office и менеджер по продажам вносит в локальную базу нового клиента. Эта информация о клиенте синхронизируется с главной базой в headquarters и становится после этого доступна для остальных branch offices.
И еще, рассматривали, как ведут себя базы в случае потери соединения? Скажем, у меня две БД в разных городах — интернет есть всегда, но вдруг чего, разное бывает — пропадает. В таких случаях, если у нас мультимастер репликация, надо будет решать конфликты по id'ам insert'ов и update'ам. Хотелось бы еще несколько слов об этом.
Из тех систем, с которыми я сталкивался проблема решается двумя способами — либо каждая база данных имеет свой непересекающийся диапазон идентификаторов, либо первичный идентификатор составной — ИД записи + ИД базы данных. Можно еще позаморачиваться с UUID в качестве идентификаторов, но это уже совсем для гурманов.
Да-да, у меня, к примеру, две ноды и больше не предвидится, id'ы идут чёт-нечёт.
Проблема не только в id.
А если так? Что будет на выходе?
А если так? Что будет на выходе?
Каким образом SymmetricDS разрешает конфликты?
А в чем преимущество над, например, slony?
Если я понимаю, разрешения конфликтов при доступе в обе нет — это master-slave репликация только?
Если я понимаю, разрешения конфликтов при доступе в обе нет — это master-slave репликация только?
В нашем проекте используется master-slave модель, когда данные пишутся только в master базу и реплицируются на находящуюся в hot standby вторичную базу.
Отвечу сразу на вопрос Lolka — при временном обрыве соединения между базами изменения в master базе накапливаются в служебных таблицах SymmetricDS, и при возобновлении соединения они загоняются в secondary db.
Вопрос об разрешении конфликтов при мультимастерной конфигурации, думаю, это тема отдельного поста. Пока же скажу, что симметрик умеет изменять запрос INSERT на UPDATE в случае, если в destination db такая запись уже есть.
Отвечу сразу на вопрос Lolka — при временном обрыве соединения между базами изменения в master базе накапливаются в служебных таблицах SymmetricDS, и при возобновлении соединения они загоняются в secondary db.
Вопрос об разрешении конфликтов при мультимастерной конфигурации, думаю, это тема отдельного поста. Пока же скажу, что симметрик умеет изменять запрос INSERT на UPDATE в случае, если в destination db такая запись уже есть.
К сожалению, полноценной мастер-мастер репликации не существует в природе. См. CAP-теорему Брюэра — это прямо следует оттуда.
Как поведет себя система в такой ситуации:
1> BEGIN;
2> BEGIN;
1> UPDATE…
2> UPDATE той же строки с другими данными
1> COMMIT;
2> COMMIT;
Как поведет себя система в такой ситуации:
1> BEGIN;
2> BEGIN;
1> UPDATE…
2> UPDATE той же строки с другими данными
1> COMMIT;
2> COMMIT;
Да, но можно решать конфликты одним из способов. Например — кто последний, тот и прав. Такое работает, не для всех данных, конечно же.
Это очень важно как он будет себя вести.
Например, rubyrep, так же позионирующийся как мастер-мастер репликатор, тупо падает в этой ситуации. А это, согласитесь, обозначает полную неприменимость.
Давно смотрел на М-М решения, но пока не видел ничего достойного.
Например, rubyrep, так же позионирующийся как мастер-мастер репликатор, тупо падает в этой ситуации. А это, согласитесь, обозначает полную неприменимость.
Давно смотрел на М-М решения, но пока не видел ничего достойного.
БД более 300G. продакшен. работаем на master-slave реплике (hot_standby WAL) + pgpool для отказоустойчивости. полет нормальный. отставание практически незаметное. pgpool допилен немного скриптами для грамотного переключения и управления нодами.
так же есть балансировка нагрузки. на slave летит 99% SELECT.
так же есть балансировка нагрузки. на slave летит 99% SELECT.
Какая у вас версия PG?
Как осуществляется переключение при выходе из строя мастера?
Как осуществляется переключение при выходе из строя мастера?
схема такая.
pgpool. 2 сервера под HA.
pgcluster. 2 сервера master-slave. все запросы идут через pgpool. он же переключает master-slave.
есть скрипты ручной/автоматической синхронизации мастера со слейвами.
на тестовом стенде делали 1 мастер 2 слейва. все прекрасно синкается, переключается, обрабатывается. отставания нод практически нет.
работает все под серверами ubuntu + pgpoolIII ( 2 проца. 2Г памяти)+ pgbonucer+pg9.0.4 (8 проц. 40Г память)
нагрузка порядка 100-200 коннектов на PG. 1000-1500 на бонусерах и пуле в сек.
п.с. в принципе есть дока… могу куда-нить выложить… наверное… =)
pgpool. 2 сервера под HA.
pgcluster. 2 сервера master-slave. все запросы идут через pgpool. он же переключает master-slave.
есть скрипты ручной/автоматической синхронизации мастера со слейвами.
на тестовом стенде делали 1 мастер 2 слейва. все прекрасно синкается, переключается, обрабатывается. отставания нод практически нет.
работает все под серверами ubuntu + pgpoolIII ( 2 проца. 2Г памяти)+ pgbonucer+pg9.0.4 (8 проц. 40Г память)
нагрузка порядка 100-200 коннектов на PG. 1000-1500 на бонусерах и пуле в сек.
п.с. в принципе есть дока… могу куда-нить выложить… наверное… =)
Интересно. Выложите :)
Как пгпул переключает слейвы? Не нужно как-то явно говорить, что такой-то слейв теперь стал мастером?
Во всяком случае в слоне так — и он просто запрещает запись на слейв сервер.
Как пгпул переключает слейвы? Не нужно как-то явно говорить, что такой-то слейв теперь стал мастером?
Во всяком случае в слоне так — и он просто запрещает запись на слейв сервер.
pgpool мониторит сервера и при отказе запускает скрипт, который и возвращает ему мастера.
Мы поостереглись делать автоматическое переключение мастера — т.к. в случае временных перебоев или еще каких сетевых проблем, начнется переконфигурация кластера.
с чего она начнется-то?
1. падает мастер.
2. pgpool делает slave мастером. в случае нескольких слейвов запускается синхронизация с новым мастером.
даже если старый мастер поднимется он не включиться в текущую схему. его можно только принудительно сделать слейвом и так же принудительно включить в кластер.
где-же тут конфликты?
1. падает мастер.
2. pgpool делает slave мастером. в случае нескольких слейвов запускается синхронизация с новым мастером.
даже если старый мастер поднимется он не включиться в текущую схему. его можно только принудительно сделать слейвом и так же принудительно включить в кластер.
где-же тут конфликты?
Представим, что где-то возник таймаут — например, за счет перебоев в сети, скачка нагрузки, где-то своп подкачался и пр. — причин может быть масса.
После этого скрипт считает, что мастер пропал — тут же все переключается на слейв. Затем мастер появился, но работать уже не может — т.к. он рассинхронизирован. Таким образом из рабочей конфигурации вы потеряли 1 сервер БД. Конфигурация ослабла. Если будет скачок нагрузки, то есть риск вылета еще одного сервера таким же макаром, а дальше все будет «складываться» как домино.
После этого скрипт считает, что мастер пропал — тут же все переключается на слейв. Затем мастер появился, но работать уже не может — т.к. он рассинхронизирован. Таким образом из рабочей конфигурации вы потеряли 1 сервер БД. Конфигурация ослабла. Если будет скачок нагрузки, то есть риск вылета еще одного сервера таким же макаром, а дальше все будет «складываться» как домино.
надо понимать, что это все-таки псевдо-кластер. да. с большим отказом, но есть узкие места.
=)
при переходе на нового мастера, слейвы должны будут посинкаться с новым мастером. старый мастер стать слейвом и тоже посинкаться. в общем есть там слабые места. есть. не спорю, но это лучше чем вообще ничего и если надо обеспечить 24Хх7 то это хоть что-то при отказах, а не тупое «БД не доступна».
=)
при переходе на нового мастера, слейвы должны будут посинкаться с новым мастером. старый мастер стать слейвом и тоже посинкаться. в общем есть там слабые места. есть. не спорю, но это лучше чем вообще ничего и если надо обеспечить 24Хх7 то это хоть что-то при отказах, а не тупое «БД не доступна».
момент переключения очень слабое место в таком конфиге. да. но пока нет ничего лучше.
все в автоматическом режиме. сиди, кури…
=)
=)
хорошая статья спасибо
позвольте поумничать
«Сервера должны пинговать друг друга, потому что SymmetricDS использует HTTP протокол для синхронизации. „
пинг это ICMP протокол, а HTTP — это другой протокол.
можно сделать чтобы сервера не пингались, а HTTP работает =)
[/умничать]
позвольте поумничать
«Сервера должны пинговать друг друга, потому что SymmetricDS использует HTTP протокол для синхронизации. „
пинг это ICMP протокол, а HTTP — это другой протокол.
можно сделать чтобы сервера не пингались, а HTTP работает =)
[/умничать]
Sign up to leave a comment.
Репликация базы данных PostgreSQL на основе SymmetricDS