event sourcing

Благодарю!

Благодарю!

Там скорее всего полприложения придется переписывать, поэтому не подойдет. Но вообще самый каноничный метод, в будущем сможете применить.

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

Есть ли юзеры юзающие asyncpg в python?

что интересует?

Есть ли юзеры юзающие asyncpg в python?

++

что интересует?

Нужна хорошая инфа о пулах и транзакциях, в доке прочитал чуть не понял

Нужна хорошая инфа о пулах и транзакциях, в доке прочитал чуть не понял

пулов не нашел, сделал свой. транзакции - https://magicstack.github.io/asyncpg/current/api/index.html#transactions, либо with контекст, либо объект транзакции. хотя дока по пулам есть - https://magicstack.github.io/asyncpg/current/api/index.html#connection-pools

добрый день. Подскажите, чем можно относительно быстро мигрировать БД размером где-то в 300 гигабайт с сервера на сервер? Перетаскивать дамп или сами файлы займёт в районе часа (а дамп восстанавливать - ещё дольше), а останавливать БД не хотелось бы. Хотелось бы поднять master-slave репликацию без остановки экземпляра самой БД

пинки в документацию приветствуются, конечно

официальная документация рекомендует либо pg_dump, либо перетаскивать файлы, эхма

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

pg_basebackup

pg_basebackup

т.е. он сделает консистентный снапшот без остановки, и для старта слейва мне достаточно будет иметь WAL начиная с момента старта pg_basebackup?

Вас в гугле забанили?

чат на английском языке: ты задаёшь вопрос, тебе отвечают. Чат на русском языке: ты задаёшь вопрос, а потом тебе долго рассказывают, какой ты мудак :)

тем не менее, большое спасибо

чат на английском языке: ты задаёшь вопрос, тебе отвечают. Чат на русском языке: ты задаёшь вопрос, а потом тебе долго рассказывают, какой ты мудак :)

Разница менталитетов

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

добрый день. Подскажите, чем можно относительно быстро мигрировать БД размером где-то в 300 гигабайт с сервера на сервер? Перетаскивать дамп или сами файлы займёт в районе часа (а дамп восстанавливать - ещё дольше), а останавливать БД не хотелось бы. Хотелось бы поднять master-slave репликацию без остановки экземпляра самой БД

https://eax.me/postgresql-replication/ я по этой статье поднял легко мастер-слейв без остановки мастера и сделал это первый раз в жизни ?

единственное нужно будет перезагрузить мастер что бы добавить в pg_hba.conf новую запись для разрешения удаленного подключения к пользователю у которого права репликации

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

спасибо большое :)

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

надеюсь не придётся задавать тупых вопросов

единственное нужно будет перезагрузить мастер что бы добавить в pg_hba.conf новую запись для разрешения удаленного подключения к пользователю у которого права репликации

Для hba reload. А вот с настройками репликации нужен перезапуск

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

тогда pg_basebackup с нужными ключами

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

Какие версии PostgreSQL источника и приёмника?

Какие версии PostgreSQL источника и приёмника?

с 10.4 на 10.5 (впрочем, если не взлетит, то поставлю 10.4 из репозитория, это не проблема)

А OS какие?

т.е. он сделает консистентный снапшот без остановки, и для старта слейва мне достаточно будет иметь WAL начиная с момента старта pg_basebackup?

Изучить документацию на предмет archive_command&restore_command, чтобы не болела голова о наличии нужных WAL-ов.

единственное нужно будет перезагрузить мастер что бы добавить в pg_hba.conf новую запись для разрешения удаленного подключения к пользователю у которого права репликации

Не надо перегружать мастер, чтобы прочитать изменения pg_hba.conf, достаточно отрелоадить средствами ОС.

Не надо перегружать мастер, чтобы прочитать изменения pg_hba.conf, достаточно отрелоадить средствами ОС.

понял, спасибо ? говорю ж что только начинаю изучать ПГ ?

официальная документация рекомендует либо pg_dump, либо перетаскивать файлы, эхма

Для создания ФИЗИЧЕСКОЙ реплики pg_dump? о_О Вы что курите?! И не надо читать чего-то из интернетов, советы в таких статьях всегда либо неполные, либое содержат неточности (archive_command&restore_command, ага), тем более, что по постгресу, благодаря Постгресу профессиональному, есть документация на русском языке: https://postgrespro.ru/docs/postgresql/10/high-availability

понял, спасибо ? говорю ж что только начинаю изучать ПГ ?

Не стоит в таком случае приводить статьи сомнительного качества из этих самых иинтернетов.

Не стоит в таком случае приводить статьи сомнительного качества из этих самых иинтернетов.

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

прошу прощения тогда, хотел помочь а вы теперь злитесь ?

А OS какие?

ubuntu и там и там

Для создания ФИЗИЧЕСКОЙ реплики pg_dump? о_О Вы что курите?! И не надо читать чего-то из интернетов, советы в таких статьях всегда либо неполные, либое содержат неточности (archive_command&restore_command, ага), тем более, что по постгресу, благодаря Постгресу профессиональному, есть документация на русском языке: https://postgrespro.ru/docs/postgresql/10/high-availability

нет, не для создания физической реплики. Не ругайтесь, возможно, я оговорился, простите. Я не dba :)

St_intersects ругаеться на коллекцию, приходиться делить запрос на коллекции и на не коллекции. Коллекцию разбиваю st dump, но тогда не работает индекс

фикс зарелизили: http://postgis.net/2018/09/16/postgis-2.5.0rc2/

ubuntu и там и там

Значит pg_basebackup годится. Если с минимальным простоем, то вот это тоже норм вариант - https://www.2ndquadrant.com/en/resources/pglogical/ https://www.depesz.com/2016/11/08/major-version-upgrading-with-minimal-downtime/

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

Тем более, что по твоим же словам, оно тормозит, причем тормозит люто.

Тем более, что по твоим же словам, оно тормозит, причем тормозит люто.

Насколько я понял - нужна именно миграция, с минимальным простоем. Сколько оно будет переливать и синхронизировать перед остановкой основной БД - вопрос второй. Главное тут - критичность времени остановки, что pglogical сводит к минимуму. А завтра человеку понадобится перелить с разных версий PG, но с теми же требованиями, а решение уже будет обкатано)))

А потоковая реплика не сводит к минимуму время простоя? о_О, Саш, ты чего вчера употреблял?

там забавная история, в общем

я вышел на новую работу

а за несколько дней до этого полетел жёсткий диск на сервере (да, там не было рейда, не спрашивайте), полетел не полностью - фс ушла в рид-онли. База постгреса лежит на SSD, а полетел другой диск, который с системой

кое-как оно работает

однако рестартануть с новыми параметрами не получится - т.к. postgresql.conf лежит на ФС, смонтированной в рид-онли (да, я знаю про mount -o bind, но всё равно лишний раз трогать неохота - не знаю, как оно себя поведёт)

задача - перетащить на другой сервер базу, минимально задействуя существующий

смонтировали по nfs каталог на втором сервере, сейчас pg_basebackup переливает БД, в параметрах сменил через alter system checkpoint_timeout на 15m

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

задача - перетащить на другой сервер базу, минимально задействуя существующий

А не получится. Вам в любом случае надо будет вычитывать все хотя бы живые данные. И pg_basebackup в этом случае предпочтительнее пофайлового копирования.

данные на другом диске, с ним всё в порядке

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

Да нет там массы способов, pg_basebackup (архивирование WAL-ов!!!), поднятие реплики, и вперёд!

Да нет там массы способов, pg_basebackup (архивирование WAL-ов!!!), поднятие реплики, и вперёд!

угу, так и делаю, только проблема в том, что archive_mode у меня выключен :)

поэтому придётся доставать WAL из pg_wal

в общем, никакого особого рокетсаенса нет

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

pg_basebackup с "-X stream"

Но для этого д/б включено max_wal_senders >= 2

А если нет, то рестарт

Куда ни кинь, везде поленом по тыковке.

по дефолту в десятке вроде 10

там с nfs тоже была история (nfs-common не был установлен), пришлось делать dpkg -x для двух пакетов и потом через LD_PRELOAD=либа ./mount_nfs ... :)

в общем, ничего такого особо ужасного

я просто с базами редко работаю, сетевой инженер

по дефолту в десятке вроде 10

show max_wal_senders в консоли для проверки

А потоковая реплика не сводит к минимуму время простоя? о_О, Саш, ты чего вчера употреблял?

Потоковая реплика, конечно, более предпочтительный вариант. Тем более, что postgresql.conf, как выяснилось, нельзя изменить. На банкет не оставался))

pg_basebackup с "-X stream"

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

Потоковая реплика, конечно, более предпочтительный вариант. Тем более, что postgresql.conf, как выяснилось, нельзя изменить. На банкет не оставался))

изменить можно (mount -o bind /tmp/pgconf /etc/postgresql), но как поведёт себя сервер при рестарте - неизвестно, поэтому не хотелось бы

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

Не надо запускать слейв параллельно с pg_basebackup, как вы себе это представляете?

pg_basebackup с опцией -X stream вам в одном подключении вытянет данные, а во втором - пишущиеся в это время WAl-ы.

Не надо запускать слейв параллельно с pg_basebackup, как вы себе это представляете?

я так понимаю, что pg_basebackup -X stream сперва дампит сами файлы БД, а затем дампит лог транзакции. Мануал говорит: Stream the write-ahead log while the backup is created. This will open a second connection to the server and start streaming the write-ahead log in parallel while running the backup. Therefore, it will use up two connections configured by the max_wal_senders parameter. As long as the client can keep up with write-ahead log received, using this mode requires no extra write-ahead logs to be saved on the master.

или я неправильно понимаю?

Слово parallel - это сперва данные, потом лог?! о_О, хренассе, неделька начинается!

Слово parallel - это сперва данные, потом лог?! о_О, хренассе, неделька начинается!

ок, параллельно данные и логи, но когда он закончит работу? Когда скопирует основные данные?

ладно, извините за тупые вопросы, разберусь. Извините за беспокойство :)

ок, параллельно данные и логи, но когда он закончит работу? Когда скопирует основные данные?

Когда скопирует основные данные и достаточно WAL для достижения консистентности полученной копии при recovery.

Когда скопирует основные данные и достаточно WAL для достижения консистентности полученной копии при recovery.

копия-то будет консистентной, но мне нужна копия, которая будет актуальной :) у меня в голове сложилась картинка (ложная, я понимаю) о том, что pg_basebackup -X stream пишет данные на момент старта, а логи продолжает писать параллельно до тех пор, пока его не прервёшь. Такое поведение было бы хорошим для бесшовного (или почти бесшовного) переноса данных на реплику: стопаем мастер, последние данные уходят на слейв, перезапускаем слейв без recovery.conf и готово. Я подумал не в ту сторону, ещё раз извините.

Всем привет, правильно понимаю, что в случае do $$ begin set enable_nestloop = False; select * from table1 inner join table2 on table1.id = table2.t1; end; $$ language 'plpgsql'; enable_nestloop = False будет применено только для текущей транзакции

копия-то будет консистентной, но мне нужна копия, которая будет актуальной :) у меня в голове сложилась картинка (ложная, я понимаю) о том, что pg_basebackup -X stream пишет данные на момент старта, а логи продолжает писать параллельно до тех пор, пока его не прервёшь. Такое поведение было бы хорошим для бесшовного (или почти бесшовного) переноса данных на реплику: стопаем мастер, последние данные уходят на слейв, перезапускаем слейв без recovery.conf и готово. Я подумал не в ту сторону, ещё раз извините.

> Копия-то будет консистентной, но мне нужна копия, которая будет актуальной :) Постоянно актуальной? Тогда Вам нужна репликация, очевидно (законченный backup же не будет обновляться волшебным образом ;) ). > что pg_basebackup -X stream пишет данные на момент старта, А где бы он мог их взять? Нет, конечно, он просто пишет то, что читает в каждый момент (считанное может представлять собой "мешанину" из неконсистентных страниц, естественно, но это неважно — "накатывание" WAL потом всё это выправит). > а логи продолжает писать параллельно до тех пор, пока его не прервёшь. Так бы он потенциально вечно их писал... А от backup-а ожидают, что он когда-нибудь закончится, обычно. :) > Такое поведение было бы хорошим для бесшовного (или почти бесшовного) переноса данных на реплику Да этот pg_basebackup и используется для инициализации реплики, которая потом "догоняется" до текущего состояния master с помощью последующего streaming/log shipping.

Всем привет, правильно понимаю, что в случае do $$ begin set enable_nestloop = False; select * from table1 inner join table2 on table1.id = table2.t1; end; $$ language 'plpgsql'; enable_nestloop = False будет применено только для текущей транзакции

Не уверен, но, кажется, это не так. Проверьте, это же легко.

Yaroslav Schekin спасибо

>А где бы он мог их взять? Нет, конечно, он просто пишет то, что читает в каждый момент (считанное может представлять собой "мешанину" из неконсистентных страниц, естественно, но это неважно — "накатывание" WAL потом всё это выправит). вот это хороший момент, спасибо

>перезапускаем слейв без recovery.conf на самом деле нужно сделать промоут реплики до мастера и не нужно перезапускать ПГ

Всем привет, правильно понимаю, что в случае do $$ begin set enable_nestloop = False; select * from table1 inner join table2 on table1.id = table2.t1; end; $$ language 'plpgsql'; enable_nestloop = False будет применено только для текущей транзакции

user=> do $$ begin set enable_nestloop = False; PERFORM * from t1 join t2 on t1.t1_id = t2.t1_id; end; $$ language 'plpgsql'; DO user=> show enable_nestloop; enable_nestloop ----------------- off (1 строка) user=> И обратите внимание на PERFORM

Спасибо

Насколько я понимаю документацию, любые параметры устанавливаются, самое малое, на сессию.

Насколько я понимаю документацию, любые параметры устанавливаются, самое малое, на сессию.

Для транзакции: "SET LOCAL enable_nestloop = false;"

Спасибо

А Вам зачем, кстати? Если пытаетесь "хинтовать", может, лучше не стоит? ;)

хотел на проде проверить запрос, но уже сделал через set enable_nestloop=false; big query; set enable_nestloop=false

на проде вместо hash join используется nestedloop и запрос очень сильно деградирует

это stable https://explain.depesz.com/s/gp5Fc

это prod https://explain.depesz.com/s/FDFo