Но это время займёт,

По доке - если не интересно описание сишной библиотеки и история изменений от версии к версии то читать там отсилы 1/3 нужно, так что не все так страшно.

тут вопрос в чём - я хочу чтобы это было как-то прозрачно для приложения

http://pgday.ru/ru/2016/papers/55

в patroni пугает необходимость в ZooKeeper, etcd или Consul, а так его внутри интересно поизучать для понимания что и как

Зукупир я бы ставил только за то, что его использует кафка

имхо, это еще одно лишнее звено

А без них никуда, самому реализовывать функциональность zookeeper/etcd/consul очень накладно. Тем более как правило, что-то из этого уже используется.

Понятно что оно точится как продукт для 1-й компании, но для "массового продукта" я бы исходил из того что ничего из этого не используется и реализовывал бы все по возможности без внешних зависимостей, тем более что там не так уж много и надо

http://pgday.ru/ru/2016/papers/55

Мне это показалось дичайшим велосипедом

Мне это показалось дичайшим велосипедом

Мне тоже, но это все равно лучше чем писать свой

если наличие zk или подобной внешней зависимости принесет железобетонную надежность и простоту эксплуатацию, то почему бы и нет?

если наличие zk или подобной внешней зависимости принесет железобетонную надежность и простоту эксплуатацию, то почему бы и нет?

простоту эксплуатации внедрение дополнительного сервиса, причем требующего несколько нод, оно особо не даст, собственно как и не принесет "железобетоннуой надежности", отсюда и вопрос

погоди, если есть задача поиметь автоматический фейловер, скейлаут (хотяб для чтения) и все такое остальное, то как ты это сделаешь без: "дополнительных сервисов" и "несколькних нод"?

никто же не предлагает стендэлон решение менять на такое

просто если уже есть задача и надо лепить, то либо начинают колхозить свое самописное на скриптах, собирая все возможные грабли

на фоне такого, наличие дополнительного сервиса типа zk не выглядит сильным сдерживающим фактором, если он приносит свои плоды

погоди, если есть задача поиметь автоматический фейловер, скейлаут (хотяб для чтения) и все такое остальное, то как ты это сделаешь без: "дополнительных сервисов" и "несколькних нод"?

зачем там скейл, там "распинговка" у машин раз в секунду, там нужно в агенты какой-либо membership а-ля https://en.wikipedia.org/wiki/Gossip_protocol организовать и все

не понял про "распинговку"

в etcd/consul etc храниться информация о том какие ноды живы, туда это агент пишет вот и все

и?

идея в том ,чтоб не было выделенного сервиса "арбитра", а делать это с помощью gossip напрямую между этими "агентами"?

типа это ща вот раз и упростило жизнь всем

и уменьшило число нод и все такое?

идея в том, что не нужно поддерживать "еще какое-то ПО", агенты вполне себе могут обмениваться информацией

а агенты это что?

что-то абстрактное будущее?

и еще, вы уверены, что gossip и zk это равно ценные замены?

может gossip это что-то об "eventual consistency"?

замены для чего ?

ну наверное я не понял вообще вашей мысли

за сим пойду я лучше поработаю

ну наверное я не понял вообще вашей мысли

просто вы пытаетесь говорить о zookeeper в отрыве от patroni, а он использует zk,etcd ... etc , вобщем-то как просто хранилище key-value чтоб "шарить" состояние между агентами на нодах с постгресом и агентом на ha-proxy который роутит на мастера

ну в общем да, я не сильно ща про патрони говорил. Я возражал на мысль вида "ууу, еще одну систему подтягивать в виде zk или подобного, это не дело" моя идея в том, что когда ты пытаешься решить задачи подобные тому, о чем патрони презентует, то наличие еще одной системы (тем более отлично проверенной в бою) не является стопфактором

если она конечно правильно и по назначению используется и без нее нельзя

Patroni хорошь тем, что у него внутри есть на что посмотреть (в плане на что обратит внимание при перекличении серверов, пересоздании реплик и прочего - это, так сказать, опыт), а вот все эти Docker/Kubernetes для СУБД, пока, не особо true way

а он прям завязан это Докер? (я пока не успел глянуть пристально)

т.е. его нельзя на нормальном железе (виртуализации) без всех этих Докеров мутить?

можно и на железе

просто у них отдельный хайп про Docker/Kubernetes, а оно для РСУБД, пока, дальше стейджинга особо не работает, и никакой HA там не нужнен, т.к. ничего серьезного с этим не сделать

Мы в свое время писали некий "PaaS", это интересный челендж, но с РСУБД там делать нечего, для стейтлес приложений - хорошо, для остальных - смерть )

Капец :-)

Ниче не понял :-)

Все должно быть просто как сапог,

А то работать не будет

ну тогда не надо пытаться наворачиваться всякие эластичные, автоматические, высокодоступные штуки

там просто быть не может

Точно

и за частую это более оправдано (на выходе доступность будет выше)

Ненадо

Потом ниче не понятно

Как оно работало, и чего там было

простоту эксплуатации внедрение дополнительного сервиса, причем требующего несколько нод, оно особо не даст, собственно как и не принесет "железобетоннуой надежности", отсюда и вопрос

зукипер - один из сервис с самыми строгими гарантиями консистентости, если ему указать правильные настройки

зукипер - один из сервис с самыми строгими гарантиями консистентости, если ему указать правильные настройки

это все здорово, но для patroni оно зачем ?

зукипер - один из сервис с самыми строгими гарантиями консистентости, если ему указать правильные настройки

а как у него при этом со скоростью, интересно?

скоростью на что?

на запись все стандартно (через один узел с репликацией синхронной)

на чтение лучше

но он не БД как бы

хотя зачастую и пытаются его так использовать

это все здорово, но для patroni оно зачем ?

Патрони скорее всего регистрирует эфемерную ноду для отслеживания, жив ли мастер, кто мастер, Также выбирает через зукипер нового мастера, чтобы не было сплитбрейна, итд

Все логично и оправдано

это все здорово, но для patroni оно зачем ?

А как еще реализовывать менеджмент кластера?

а как у него при этом со скоростью, интересно?

Туда не сами записи пишутся, насколько понимаю.

https://xakep.ru/2016/08/11/coding-challenges-211/

А как еще реализовывать менеджмент кластера?

Ну наличие общего key-value хранилища это еще не менеджмент класстра, а вообще, если уж поднакинуть, то раз там есть агенты на машинах то они, вполне себе, могли бы собирать часть метрик с машин и инстанца постгреса и складывать их в какое-либо хранилище метрик, чтоб потом по ним можно было нормальный дашборд и графики на весь этот кластер повесить и видеть что там и как, такое вот "комплексное" решение )

если наличие zk или подобной внешней зависимости принесет железобетонную надежность и простоту эксплуатацию, то почему бы и нет?

Надёжность это не равнозначное значение, к сожалению, надо смотреть что больше надо: доступность или сохранность или скорость, для всех трёх, надо очень постараться и там в любом случае будет зоопарк. Еще есть pacemaker, вместо zookeeper

Ну наличие общего key-value хранилища это еще не менеджмент класстра, а вообще, если уж поднакинуть, то раз там есть агенты на машинах то они, вполне себе, могли бы собирать часть метрик с машин и инстанца постгреса и складывать их в какое-либо хранилище метрик, чтоб потом по ним можно было нормальный дашборд и графики на весь этот кластер повесить и видеть что там и как, такое вот "комплексное" решение )

+1024 причём не только метрики но и поисковый индекс по данным вообще, если требуется, тоже хочу у себя так сделать

Не могу dba в мск захантить никак ;(

Комрады, мож покритикуете вакансию?

http://pastebin.com/f9Q9QW4g

Кстати, еще по HA можно посмотреть http://www.cubrid.org/manual/10_0/en/ha.html и имплементировать для постгреса )

Я сегодня чемпион, запустил репак и импорт в пгмоделлер одновременно

Выдать мне медаль

Хехе

?

Сижу такой, смотрю что то не то, после 4 чашки чая я допер

Что не то :-)

ггг

?

Ну наличие общего key-value хранилища это еще не менеджмент класстра, а вообще, если уж поднакинуть, то раз там есть агенты на машинах то они, вполне себе, могли бы собирать часть метрик с машин и инстанца постгреса и складывать их в какое-либо хранилище метрик, чтоб потом по ним можно было нормальный дашборд и графики на весь этот кластер повесить и видеть что там и как, такое вот "комплексное" решение )

при чем здесь key-value не key-value? я про гарантии консистентности

А кому их гарантировать, а главное чего в данном конкретном случае ? )

Всем привет! Тут недавно поднимали тему с мониторингом долгих запросов. Мы в postgrespro запилили расширение, которое позволяет посмотреть внутрь сессии и узнать состояние запроса. Будет выводиться план запроса со статистикой, аналогичной той, что от EXPLAIN ANALYZE. Расширение доступно по ссылке https://github.com/postgrespro/pg_query_state и требует пропатчивания ядра постгреса последней версии 9.5.

ура!

Всем привет! Тут недавно поднимали тему с мониторингом долгих запросов. Мы в postgrespro запилили расширение, которое позволяет посмотреть внутрь сессии и узнать состояние запроса. Будет выводиться план запроса со статистикой, аналогичной той, что от EXPLAIN ANALYZE. Расширение доступно по ссылке https://github.com/postgrespro/pg_query_state и требует пропатчивания ядра постгреса последней версии 9.5.

а можно рисовать прогрессбар для запросов прямо нотисами, начиная с 30й секунды выполнения? :)

Всем привет! Тут недавно поднимали тему с мониторингом долгих запросов. Мы в postgrespro запилили расширение, которое позволяет посмотреть внутрь сессии и узнать состояние запроса. Будет выводиться план запроса со статистикой, аналогичной той, что от EXPLAIN ANALYZE. Расширение доступно по ссылке https://github.com/postgrespro/pg_query_state и требует пропатчивания ядра постгреса последней версии 9.5.

а патчи ваши примут? т.е. есть ли надежда, что там в 9.6 или дальше надо будет просто устанавливать экстеншн?

http://reorg.projects.pgfoundry.org/pg_reorg.html можно ли это применять для боевой Pg 9.4?

@maksm90 вообще, можно ли из такого плана посчитать ETA запроса?

Ну прогрессбар вообще штука непростая. Мы работаем в этом направлении. Там проблема с ошибками планировщика и выходом прогресса за 100%. Но вывод по нотисами не очень. Можно просто обращениями к пиду выводить. А уж как часто - определяет юзер

а патчи ваши примут? т.е. есть ли надежда, что там в 9.6 или дальше надо будет просто устанавливать экстеншн?

на 9.6 надежды уже быть не может, конечно

фичи зафризили уже

Хорошо

Патчи сейчас рассматриваются в хакерс и мы их дальше будем проталкивать

У меня вопрос, странный, кто баловался с ora2pg на больших базах?

Ну тер 30 так

Суть в том что он тупит

За сутки 200 гиг слил и все

@Komzpa можно на глаз оценить ETA, отталкиваясь от числа отработанных записей внутри дерева