пришло время объективности! вот что мне удалось понять из написанного: 1) я бестолковый разработчик 2) у меня скоро сгорит сервер с дисками 3) нужно разработать модель бэкапирования и ресторинга ?)

ощущение что мне хотят облако продать ))))

Да ничего Вам не хотят продать, Вас спрашивают, насколько Вам (или Вашим заказчикам) это критично...

есть ли способ узнать через консоль, закончилась ли первоначальная синхронизация таблиц при логической репликации? в логи постгрес пишет по каждой таблице: LOG: logical replication table synchronization worker for subscription "demo", table "users" has started LOG: logical replication table synchronization worker for subscription "demo", table "users" has finished вот бы скриптами тоже узнать можно было (без парсинга логов)

нашёл pg_subscription_rel, надеюсь это то, что нужно

пришло время объективности! вот что мне удалось понять из написанного: 1) я бестолковый разработчик 2) у меня скоро сгорит сервер с дисками 3) нужно разработать модель бэкапирования и ресторинга ?)

> 1) я бестолковый разработчик Я такого не писал. Вы просто как-то несерьёзно относитесь к возможным проблемам. ;) Кстати: > и вообще весь Питер разбомбят нахер и моей базе кабзец Такое с базами, в разработке которых я участвовал, тоже бывало, кстати (только город был другой). :( > 2) у меня скоро сгорит сервер с дисками Это не исключено. И что Вы собираетесь делать? > 3) нужно разработать модель бэкапирования и ресторинга ?) Конечно, нужно. Так всё же, я спрашивал не только с этой целью: > нет потерь на данном участке, у нас нюк всё пишет в очередь если базы нет, а когда появляется - пишет всё из очереди в базу А если база (или сеть) "упала" прямо в процессе записи, как он знает, писать ему снова данный "кусок" данных или нет?

> 1) я бестолковый разработчик Я такого не писал. Вы просто как-то несерьёзно относитесь к возможным проблемам. ;) Кстати: > и вообще весь Питер разбомбят нахер и моей базе кабзец Такое с базами, в разработке которых я участвовал, тоже бывало, кстати (только город был другой). :( > 2) у меня скоро сгорит сервер с дисками Это не исключено. И что Вы собираетесь делать? > 3) нужно разработать модель бэкапирования и ресторинга ?) Конечно, нужно. Так всё же, я спрашивал не только с этой целью: > нет потерь на данном участке, у нас нюк всё пишет в очередь если базы нет, а когда появляется - пишет всё из очереди в базу А если база (или сеть) "упала" прямо в процессе записи, как он знает, писать ему снова данный "кусок" данных или нет?

1) ? 3) в планах тут пропадет всего 10 записей максимум (это уже не критично)

1) ? 3) в планах тут пропадет всего 10 записей максимум (это уже не критично)

> тут пропадет всего 10 записей максимум (это уже не критично) Ещё одна причина запомнить на будущее возможность сделать "synchronous_commit = off". (Т.е. потеря есть потеря, раз она допустима (если маловероятна, как я понимаю), причины не так важны, а на Вашем "железе" это может сильно помочь.) Тем не менее... что с другими вопросами? > По одной строке, по много? Какой ширины? 10 строк на транзакцию, так? Размер строки Вы посмотрели? И по нагрузке подробнее... Сколько tps с одного источника? Они все постоянно пишут?

И ещё... > а когда появляется - пишет всё из очереди в базу Т.е. в приниципе (если у Вас нагрузка может сильно меняться) Вашим клиентам на самом деле неважно, насколько медленно отвечает сервер, они вполне способны "дописать потом", так?

@dezconnect будет жить. Поприветствуем!

Тут интересный вопрос возник, столкнулся с базой, которую рестартанули и она нашла последний чекпоинт месячной давности и начала с него восстанавливаться. Вопрос, как такое могло получиться ? Ведь я как я понимаю чекпоинт должен проходить каждые пять минут (значение по умолчанию), и при бекапах которые делаются через pg_basebackup ?

Тут интересный вопрос возник, столкнулся с базой, которую рестартанули и она нашла последний чекпоинт месячной давности и начала с него восстанавливаться. Вопрос, как такое могло получиться ? Ведь я как я понимаю чекпоинт должен проходить каждые пять минут (значение по умолчанию), и при бекапах которые делаются через pg_basebackup ?

А что говорит pg_controldata?

При установке на Ubuntu 16.04 из репозитория https://apt.2ndquadrant.com/ этот файл создаётся автоматически. Как устанавливаете и на какую систему?

При установке на Ubuntu 16.04 из репозитория https://apt.2ndquadrant.com/ этот файл создаётся автоматически. Как устанавливаете и на какую систему?

CENTOS 7. Только этого файла нет. Как я понял, если я инитил кластер с одним конфигом repmgr, а сейчас его исправил для auto failover, то мне теперь переинициализировать кластер придется?

При установке на Ubuntu 16.04 из репозитория https://apt.2ndquadrant.com/ этот файл создаётся автоматически. Как устанавливаете и на какую систему?

https://medium.com/@victor.boissiere/how-to-setup-postgresql-cluster-with-repmgr-febc2f10c243 Меня только вопрос авто фэйловером интересует, не могли бы вы помочь? Centos 7. Кластер проиничен. 1 мастер, второй слейв с репликами.

Короче в конфигах repmgr.conf раньше не были прописаны команды для автофэиловера, но теперь прописал, что необходимо сделать, чтобы он переинитил конфигурационный файл? Не пересобирать кластер же. ?

А что говорит pg_controldata?

Да сейчас то все окей говорит. Хочется понять что могло к этому привести

так как его место в кластере занял слейв

Короче в конфигах repmgr.conf раньше не были прописаны команды для автофэиловера, но теперь прописал, что необходимо сделать, чтобы он переинитил конфигурационный файл? Не пересобирать кластер же. ?

Видимо версия какая-то старая установлена, а документацию читаете от новой версии. Какая версия repmgr?

Удалить его и подключить в качестве standby.

Видимо версия какая-то старая установлена, а документацию читаете от новой версии. Какая версия repmgr?

10.какой-то

Видимо версия какая-то старая установлена, а документацию читаете от новой версии. Какая версия repmgr?

не, уже норм, просто перезапускаешь и реинитит он.

Удалить его и подключить в качестве standby.

А автоматизировать процесс возможно?

10.какой-то

Нее, 3 или 4 должен быть.

А автоматизировать процесс возможно?

Пишите скрипты. Но такое обычно руками разруливают.

Поздравляю, у вас splitbrain. Автоматизировать невозможно. Почти всегда только человек может решить, какой мастер оставить. Особенно, если после splitbrain писали в оба мастера.

@Snipe24 будет жить. Поприветствуем!

всем привет. не очень знаком с sql (раньше работал с nosql). вопрос такой. юзер загружает фото на сайт, надо все это хранить в базе (redshift). структура такая photo_id: string takendate : float photo_tags [массив строк, или массив обьектов] а потом мне надо делать запрос на теги по отдельному фото, и по всем тегам всех фото в целом. как это лучше организовать. две таблицы, или там теги можно как массив хранить ?

можно как массив

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

ну как массив можно, но тогда взять все теги всех фото не будет сложно ?

Если в SQL раньше не работали, лучше отдельную таблицу, имхо. Более традиционный подход.

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

Если в SQL раньше не работали, лучше отдельную таблицу, имхо. Более традиционный подход.

об этом тоже думал, но проблема в том, что я не знаю количество тегов. то есть для одного фото тегов будет 5, для другого 10. ну изначально я думал создать таблицу для тегов с несколько полями, где будет каждый тег, и еще поле id photo, который сслыяется на поле фото в другой таблице, но вот количество тегов я не знаю

об этом тоже думал, но проблема в том, что я не знаю количество тегов. то есть для одного фото тегов будет 5, для другого 10. ну изначально я думал создать таблицу для тегов с несколько полями, где будет каждый тег, и еще поле id photo, который сслыяется на поле фото в другой таблице, но вот количество тегов я не знаю

Не понимаю, если честно, в чём сложность. Сколько тегов, столько операций INSERT, грубо говоря (bulk insert в качестве упрощения не рассматриваем).

Не понимаю, если честно, в чём сложность. Сколько тегов, столько операций INSERT, грубо говоря (bulk insert в качестве упрощения не рассматриваем).

а тупанул, извините. просто у меня база redshift, это вроде похож на pgsql, но там много отличается. columnar, как называется

Доброго всем. Слышал слухи, что repmgr может что то похожее на master-master c postgre (бесплатной). На сколько миф? пробовал мож кто? Есть может ссылка, чтоб прогуляться почитать?

Доброго всем. Слышал слухи, что repmgr может что то похожее на master-master c postgre (бесплатной). На сколько миф? пробовал мож кто? Есть может ссылка, чтоб прогуляться почитать?

А причем тут repmgr?

суть как бы проста. Имея 2 цод - можно сделать master-stb1-stb2-stb3. И если подсети все доступны, проблем особых нет. Но что делать, если цод-ов - гораздо больше? шт10 например. аля хайлоад

А причем тут repmgr?

Пытаюсь понять на что способен он. Заметил просто обсуждение сегодня на счет failover.

failover - скажем так, решений много. Не самое страшное..

В любом случае мастер у вас будет один.

Из готовых решений: Patroni, Stolon.

Вот патрони как раз изучаю, ковыряю. но с балансировкой, всё равно не до конца понял. Т.е. - для RW всё равно используем только 1 мастер? Балансер отдельно как то для этого настравивается?

ну патрони вам вроде мастер-мастер не обещает совсем

Доброго всем. Слышал слухи, что repmgr может что то похожее на master-master c postgre (бесплатной). На сколько миф? пробовал мож кто? Есть может ссылка, чтоб прогуляться почитать?

Не может.

@akhanteev будет жить. Поприветствуем!

Господа, вечер добрый, кто может помочь с оптимизацией запросов/индексов на выборку из двух больших таблиц(2м+) с inner_join и сортировкой? P.S. Гуглил

Господа, вечер добрый, кто может помочь с оптимизацией запросов/индексов на выборку из двух больших таблиц(2м+) с inner_join и сортировкой? P.S. Гуглил

Индексы делаются под ограничения (constraints) и запросы, а не на "всякий случай". Т.е. смотреть нужно на что-то конкретное.

Индексы делаются под ограничения (constraints) и запросы, а не на "всякий случай". Т.е. смотреть нужно на что-то конкретное.

Естественно, что я не вешаю индексы на таблицу как на новогоднюю елку игрушки

Естественно, что я не вешаю индексы на таблицу как на новогоднюю елку игрушки

Ну а какой тогда конкретный вопроc? Или, лучше, запрос(ы)?

Естественно, что я не вешаю индексы на таблицу как на новогоднюю елку игрушки

логично, еще три месяца

:trollface:

Вопрос следующий, есть две таблицы, джойнятся по ключю, хочется уметь быстро делать выборку с сортировкой по датам/каунтам

select rm.member_id, count(rm.role_id) AS roles_count from role_member rm group by rm.member_id order by roles_count Sort (cost=415671.79..418096.32 rows=969812 width=25) (actual time=3297.260..3632.730 rows=1576914 loops=1) " Output: member_id, (count(role_id))" Sort Key: (count(rm.role_id)) Sort Method: external merge Disk: 63136kB -> GroupAggregate (cost=0.56..296031.86 rows=969812 width=25) (actual time=0.042..2540.739 rows=1576914 loops=1) " Output: member_id, count(role_id)" Group Key: rm.member_id -> Index Only Scan using role_member_member_id_role_id_index on public.role_member rm (cost=0.56..267080.50 rows=3850648 width=61) (actual time=0.035..1566.461 rows=3850648 loops=1) " Output: member_id, role_id" Heap Fetches: 1020171 Planning time: 0.155 ms Execution time: 3724.649 ms Как тут быть и что сделать, что бы было быстрее(кроме как создавать отдельное поле для каунта)

А автоматизировать процесс возможно?

Удалить репмгр и поставить патрони.

patroni

Очень захватывающий видосик, как разруливаются такие ситуации: http://thesecretlivesofdata.com/raft/

Удалить репмгр и поставить патрони.

repmgr вроде умеет automatic failover, нет?

select rm.member_id, count(rm.role_id) AS roles_count from role_member rm group by rm.member_id order by roles_count Sort (cost=415671.79..418096.32 rows=969812 width=25) (actual time=3297.260..3632.730 rows=1576914 loops=1) " Output: member_id, (count(role_id))" Sort Key: (count(rm.role_id)) Sort Method: external merge Disk: 63136kB -> GroupAggregate (cost=0.56..296031.86 rows=969812 width=25) (actual time=0.042..2540.739 rows=1576914 loops=1) " Output: member_id, count(role_id)" Group Key: rm.member_id -> Index Only Scan using role_member_member_id_role_id_index on public.role_member rm (cost=0.56..267080.50 rows=3850648 width=61) (actual time=0.035..1566.461 rows=3850648 loops=1) " Output: member_id, role_id" Heap Fetches: 1020171 Planning time: 0.155 ms Execution time: 3724.649 ms Как тут быть и что сделать, что бы было быстрее(кроме как создавать отдельное поле для каунта)

А где тут вторая таблица?

А где тут вторая таблица?

Уже спилил вторую

repmgr вроде умеет automatic failover, нет?

Он не умеет переключать обратно мастер в стэнд бай

Нативно, а патрони в автомате умеет

Нативно, а патрони в автомате умеет

Понятно, спасибо (я сам automatic failover не пользуюсь, просто видел в документации)!

select rm.member_id, count(rm.role_id) AS roles_count from role_member rm group by rm.member_id order by roles_count Sort (cost=415671.79..418096.32 rows=969812 width=25) (actual time=3297.260..3632.730 rows=1576914 loops=1) " Output: member_id, (count(role_id))" Sort Key: (count(rm.role_id)) Sort Method: external merge Disk: 63136kB -> GroupAggregate (cost=0.56..296031.86 rows=969812 width=25) (actual time=0.042..2540.739 rows=1576914 loops=1) " Output: member_id, count(role_id)" Group Key: rm.member_id -> Index Only Scan using role_member_member_id_role_id_index on public.role_member rm (cost=0.56..267080.50 rows=3850648 width=61) (actual time=0.035..1566.461 rows=3850648 loops=1) " Output: member_id, role_id" Heap Fetches: 1020171 Planning time: 0.155 ms Execution time: 3724.649 ms Как тут быть и что сделать, что бы было быстрее(кроме как создавать отдельное поле для каунта)

А зачем у Вас "COUNT(rm.role_id)"? Они могут быть NULL?

А зачем у Вас "COUNT(rm.role_id)"? Они могут быть NULL?

могут, каунт нужен для отображения

могут, каунт нужен для отображения

Ясно. Во-первых, сделайте: "VACUUM ANALYZE role_member;" Потом покажите новый EXPLAIN (ANALYZE, BUFFERS).

Ясно. Во-первых, сделайте: "VACUUM ANALYZE role_member;" Потом покажите новый EXPLAIN (ANALYZE, BUFFERS).

К сожалению уже не за машиной, буду разбираться на выходных, спасибо!

К сожалению уже не за машиной, буду разбираться на выходных, спасибо!

Во-вторых, какое у Вас железо / сколько соединений? Спрашиваю из-за этого: > Sort Method: external merge Disk: 63136kB Если есть вариант повысить work_mem, может быть быстрее. А моя первая рекомендация из-за вот этого: > Heap Fetches: 1020171

Но, в общем, этот запрос выбирает и возвращает довольно большой результат (1 576 914 rows). Вы даже просто попробуйте результат этого запроса выбрать в другую таблицу, а потом сделать SELECT * FROM из неё. Мне кажется, даже его чтение и передача займёт существенное время (это на тему предварительной аггрегации).

Во-вторых, какое у Вас железо / сколько соединений? Спрашиваю из-за этого: > Sort Method: external merge Disk: 63136kB Если есть вариант повысить work_mem, может быть быстрее. А моя первая рекомендация из-за вот этого: > Heap Fetches: 1020171

Спасибо за помощь, буду смотреть как лучше построить всю архитектуру :)

А зачем такой фетч большой? Вы потом где-то этот миллион перебираете?

Удалить репмгр и поставить патрони.

Я поставил репмгр, потому что патрони не работал. Попробую ещё раз почитаю про патрони. Спасибо.

Я поставил репмгр, потому что патрони не работал. Попробую ещё раз почитаю про патрони. Спасибо.

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

select rm.member_id, count(rm.role_id) AS roles_count from role_member rm group by rm.member_id order by roles_count Sort (cost=415671.79..418096.32 rows=969812 width=25) (actual time=3297.260..3632.730 rows=1576914 loops=1) " Output: member_id, (count(role_id))" Sort Key: (count(rm.role_id)) Sort Method: external merge Disk: 63136kB -> GroupAggregate (cost=0.56..296031.86 rows=969812 width=25) (actual time=0.042..2540.739 rows=1576914 loops=1) " Output: member_id, count(role_id)" Group Key: rm.member_id -> Index Only Scan using role_member_member_id_role_id_index on public.role_member rm (cost=0.56..267080.50 rows=3850648 width=61) (actual time=0.035..1566.461 rows=3850648 loops=1) " Output: member_id, role_id" Heap Fetches: 1020171 Planning time: 0.155 ms Execution time: 3724.649 ms Как тут быть и что сделать, что бы было быстрее(кроме как создавать отдельное поле для каунта)

Что если попробовать role_id хранить в array в одной строке с member_id, тогда можно построить индекс по выражению length(rolles_id)

Что если попробовать role_id хранить в array в одной строке с member_id, тогда можно построить индекс по выражению length(rolles_id)

А толку-то? Всё равно вся таблица будет выбираться. :(

А толку-то? Всё равно вся таблица будет выбираться. :(

Почему? Из-за order by length(roles_id) можно выдавать строки в порядке индекса без сортировки

Почему? Из-за order by length(roles_id) можно выдавать строки в порядке индекса без сортировки

Да уж куда быстрее отсортировать, почти наверняка.

Ну можно добавить member_id в индекс :) будет index only

Там наверняка order by limit X

Ну можно добавить member_id в индекс :) будет index only

Да, это вариант, но даже так, не факт, что это будет быстрее.

Там наверняка order by limit X

Да если бы... тогда был бы совсем другой разговор. ;)

@trentclainor будет жить. Поприветствуем!

Подскажите, пожауйлста, а если у меня ничего из этого не стоит, то Patroni не будет работать?

Подскажите, пожауйлста, а если у меня ничего из этого не стоит, то Patroni не будет работать?

Они используют эти зависимости как провайдер функциональности, которую сами не реализовали, поэтому работать это без etcd, zookeeper и т.д. не будет

Что-то придется выбрать)