А в прошлый раз я Oni и не заметила, а тоже отличная ) Сюжет, конечно, линейный, но комбинаторика приемов для того времени — ого-го! НЕу и графика, и саундтрек )
А если Serv1 даунтаймит не секунду, а 3-4часа? Например проблемы в ДЦ?
Тогда получается, что пока он в оффлайне, запись ведется на Serv2 и при апе 1го у него уже нехилое отставание.
А если не мастерить Serv2, то как не потерять данные? Ведь процесс копирования бд тоже не моментен, и пока Serv2 будет копироваться на Serv1 на него еще успеет набежать.
И вот оно либо бесконечное копирование, либо потеря данных.
Если я не ошибаюсь, то без мастер-режима pg_start_backup и вовсе не заработает (чтоб остановить изменение бинарной data)
Как раз хотела написать, что железо не обязательно эквивалентно.
Например основной сервер — мощнее и быстрее, а резервный предназначен исключительно для временного перехвата потоков, но не готов к полноценной нагрузке.
Про repmgr знаю.
В начале написала, что предположим ничего нет кроме самого постгреса со встроенной репликацией. И sudo нет. Ничего нет, а делать что то надо :)
А насчет trigger_file… Если честно, то у меня реакция на него так и не заработала. К тому же он всего лишь открывает доступ на запись, но не переводит слейв в состояние мастера, что впоследствие необходимо.
С первой фразы поняла )
Думаю можно прокинуть ssh туннель. Насчет напрямую — не думаю (непосредственного встроенного ф-ционала нет)
Может можно сам коннект прописать по хитрому. Не знаю, к сожалению, не пробовала
Соглашусь, но не полностью.
Красота, конечно, плюс — но не решающий.
На первом месте при оценке все равно функциональность, потом юзабилити, а потом только эстетика.
Насчет гикости не будем разводить демагогий и баттхертов )
Но «домашние» дистры у той же *убунты уже вполне юзерс-френдли.
И совсем другое дело — среда разработки (о которой в общем то речь и идет)
Основной бонус — простота. Он не настолько страшен, как кажется. Просто в нем нет красивых формочек и няшных значков, чья красота и няшность не несут ф-циональной нагрузки.
Все коротко и очевидно. Панель тут, панель тут, схема посередке.
Для небольших объемов объектов БД удобно, что на разбирание в программе времени уйдет куда меньше, чем на саму проектировку.
Тот же EnterpriseDB например — явно перегружен и коряв (к тому же онли-вин, но дело было недобровольное)
А в отличие от PgModeler'a большой плюс- это подключение живых баз.
Что категорически не подошло — так это невозможность подключить существующую базу и грабнуть оттуда структуру.
Т.е. если требуется доработка существуюшей — то ее придется вбивать руками, что есть бред сивой кобылы.
И второе — нет поддержки ENUM и пользовательских типов (а то и вовсе нестандартных), что тоже, увы, критично
У постгреса еще общирный встроеный функционал plpgsql, позволяющий проводить более качественные оптимизации на уровне запросов к базе. А так же приличная поддержка сторонних языков (plperl, c, tkl и проч)
Я не большой мастак по писанине, но буду стараться ) Спасибо )
Грабли на которые я напоролся при синхронной репликации: если слэйв один и он упал, то мастер на все запросы записи в базу тупо не будет отвечать ибо он ждёт когда эти данные не запишутся уже лежащий слейв. synchronous_standby_names можно менять на лету и отключить репликацию, но уже «висящие» запросы придётся как-то убивать.
Вот поэтому синхронную не рассматривали. Потому что большие клиентские запросы и такие подвисающие запросы недопустимы
А с триггер файлом см выше: он дает право на запись и только. НЕ делая мастером
Не сделать мастером, а просто открыть возможность записи.
Тогда получается, что пока он в оффлайне, запись ведется на Serv2 и при апе 1го у него уже нехилое отставание.
А если не мастерить Serv2, то как не потерять данные? Ведь процесс копирования бд тоже не моментен, и пока Serv2 будет копироваться на Serv1 на него еще успеет набежать.
И вот оно либо бесконечное копирование, либо потеря данных.
Если я не ошибаюсь, то без мастер-режима pg_start_backup и вовсе не заработает (чтоб остановить изменение бинарной data)
Например основной сервер — мощнее и быстрее, а резервный предназначен исключительно для временного перехвата потоков, но не готов к полноценной нагрузке.
В начале написала, что предположим ничего нет кроме самого постгреса со встроенной репликацией. И sudo нет. Ничего нет, а делать что то надо :)
А насчет trigger_file… Если честно, то у меня реакция на него так и не заработала. К тому же он всего лишь открывает доступ на запись, но не переводит слейв в состояние мастера, что впоследствие необходимо.
rsync'аются же бинарники, которые на мастере после pg_start_backup не меняются.
Думаю можно прокинуть ssh туннель. Насчет напрямую — не думаю (непосредственного встроенного ф-ционала нет)
Может можно сам коннект прописать по хитрому. Не знаю, к сожалению, не пробовала
Можно чуть уточнить вопрос? Что Вы имеете ввиду под проксирующим скриптом?
Красота, конечно, плюс — но не решающий.
На первом месте при оценке все равно функциональность, потом юзабилити, а потом только эстетика.
Насчет гикости не будем разводить демагогий и баттхертов )
Но «домашние» дистры у той же *убунты уже вполне юзерс-френдли.
И совсем другое дело — среда разработки (о которой в общем то речь и идет)
Основной бонус — простота. Он не настолько страшен, как кажется. Просто в нем нет красивых формочек и няшных значков, чья красота и няшность не несут ф-циональной нагрузки.
Все коротко и очевидно. Панель тут, панель тут, схема посередке.
Для небольших объемов объектов БД удобно, что на разбирание в программе времени уйдет куда меньше, чем на саму проектировку.
Тот же EnterpriseDB например — явно перегружен и коряв (к тому же онли-вин, но дело было недобровольное)
А в отличие от PgModeler'a большой плюс- это подключение живых баз.
Что категорически не подошло — так это невозможность подключить существующую базу и грабнуть оттуда структуру.
Т.е. если требуется доработка существуюшей — то ее придется вбивать руками, что есть бред сивой кобылы.
И второе — нет поддержки ENUM и пользовательских типов (а то и вовсе нестандартных), что тоже, увы, критично
Имеется ввиду, например, использование тех же индексов получая вместо фуллскана индексскан
С другой стороны, можно одни и те же результаты выборки получать несколько по разному формируя запрос и тем самым вызывая разные Scan'ы
Я не большой мастак по писанине, но буду стараться ) Спасибо )
Вот поэтому синхронную не рассматривали. Потому что большие клиентские запросы и такие подвисающие запросы недопустимы