Нарежьте схем, насоздавайте тс и файлов, переносите постепенно.

Это не быстро, муторно конечно, но относительно норм. Есть окно недоступности?

Нарежьте схем, насоздавайте тс и файлов, переносите постепенно.

А как Вы советуете переносить-то? Просили же в другую БД, нет?

А как Вы их разделяете? Но, в любом случае, если хотите "распиливать" базу, Вас ждёт dump/restore (ну или логическая репликация, если уж заморочиться). :(

А если так? (чтоб без бэкапа): взять директорию с данными tablespace, перенести на другой сервер. Дальше как-то (интересно как) перенести метаданные, касающиеся перенесённого tablespace и объектов (таблиц, индексов) в нём лежащих

задача следующая: есть БД, с которой работают микросервисы. Данные каждого микросервиса лежат в отдельном tablespace. Возникла задача "распилить" единую БД по принципу "один микросервис — одна БД". Как это сделать?

1. Создаёте целевые базы данных со всеми необходимыми таблицами (только структура)(pg_dump/restore). 2. Настраиваете логическую репликацию таблиц из ресурсной БД в целевую (pglogical).

А если так? (чтоб без бэкапа): взять директорию с данными tablespace, перенести на другой сервер. Дальше как-то (интересно как) перенести метаданные, касающиеся перенесённого tablespace и объектов (таблиц, индексов) в нём лежащих

... Получить битый кластер, восстановиться из backup-а, больше такого не пробовать. ;)

1. Создаёте целевые базы данных со всеми необходимыми таблицами (только структура)(pg_dump/restore). 2. Настраиваете логическую репликацию таблиц из ресурсной БД в целевую (pglogical).

а без репликации?

Парни, подскажите пожалуйста, при использовании pg_pathman, когда выполняем слияние партиций (merge_range_partitions), будут ли блокировки?

Будут, для родительской ShareUpdateExclusiveLock, для разбиваемых - AccessExclusiveLock

Будут, для родительской ShareUpdateExclusiveLock, для разбиваемых - AccessExclusiveLock

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

а без репликации?

Только дамп/ресторе с простоем проектов на время этого безобразия. Физически перетащить файлы БД - никак от слова совсем.

задача следующая: есть БД, с которой работают микросервисы. Данные каждого микросервиса лежат в отдельном tablespace. Возникла задача "распилить" единую БД по принципу "один микросервис — одна БД". Как это сделать?

Прошу прощения за оффтоп. А микросервисы одним и тем же пользователем подключаются или разными? Я такое часто видела на оракл. На каждый микросервис отдельная схема (схема в терминологии оракла)

а без репликации?

Yaroslav выше рассказал - pg_dump/restore

Прошу прощения за оффтоп. А микросервисы одним и тем же пользователем подключаются или разными? Я такое часто видела на оракл. На каждый микросервис отдельная схема (схема в терминологии оракла)

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

Только дамп/ресторе с простоем проектов на время этого безобразия. Физически перетащить файлы БД - никак от слова совсем.

+1 Ага, проходили уже.

А в pg есть понятие схем?

А в pg есть понятие схем?

А куда оно делось?! о_О

+1 Ага, проходили уже.

(Подумав) Ну ещё можно попробовать FDW, кстати.

А куда оно делось?! о_О

У оракла есть понятие схемы, которое подразумевает учетку и все принадлежащие ей объекты - индексы, процедурки, триггеры

(Подумав) Ну ещё можно попробовать FDW, кстати.

Это для сильных духом и упоротых по самые помидоры по части рукоблудия и красноглазия. :)

Я про такую схему

(Подумав) Ну ещё можно попробовать FDW, кстати.

Сложно синхронизировать обновляющиеся данные. Нет?

У оракла есть понятие схемы, которое подразумевает учетку и все принадлежащие ей объекты - индексы, процедурки, триггеры

В пг у схемы может быть свой овнер

А в pg есть понятие схем?

Схема — это из стандарта SQL, мне помнится. Мы тут на него молимся, так что у нас есть. ;)

Только дамп/ресторе с простоем проектов на время этого безобразия. Физически перетащить файлы БД - никак от слова совсем.

т.е. без бэкапа или репликакции совсем-совсем никак?? А переносом файлов tablespace ничего не добиться? Это было бы наиболее быстрым и эффективным способом, согласитесь...

Всё остальное - также своё: объекты, права доступа, ну и вот это фсйо

Это для сильных духом и упоротых по самые помидоры по части рукоблудия и красноглазия. :)

Это да. Но "тоже вариант". ;)

т.е. без бэкапа или репликакции совсем-совсем никак?? А переносом файлов tablespace ничего не добиться? Это было бы наиболее быстрым и эффективным способом, согласитесь...

Я знаю русскава езыка?! Написано, и не раз: дамп/рестор и/или логическая репликация.

Просто после этого я ни раз н сталкивалась с такой организацией данных что бы одной схеме дали какие-то доступы на объекты других схем. Думала это вышло из моды ?, а нет это в микросервисной архтектуре опять процветает

А как Вы советуете переносить-то? Просили же в другую БД, нет?

Алгоритм такой: Готовим новую бд, все новые клиенты сливают данные в нее в свои тс и схемы. Создаем схемы и тс для существующих Заливаем данные через линк из старой бд в новую, где они отложены в свои тс (рекомендую завести отдельные тс для индексов) С окном недоступности переключаем клиентов. Профит

А логическая репликация - это дамп/рестор на схему без данных. * глумливо* Нет в мире счастья, а в жизни совершенства

т.е. без бэкапа или репликакции совсем-совсем никак?? А переносом файлов tablespace ничего не добиться? Это было бы наиболее быстрым и эффективным способом, согласитесь...

С минимальным простоем и посложнее - логическая репликация pglogical. Попроще и с бОльшим простоем - pg_dump/restore

Я знаю русскава езыка?! Написано, и не раз: дамп/рестор и/или логическая репликация.

Зачем ругаеся, насяльника? :) Хотел уточнить.

Просто после этого я ни раз н сталкивалась с такой организацией данных что бы одной схеме дали какие-то доступы на объекты других схем. Думала это вышло из моды ?, а нет это в микросервисной архтектуре опять процветает

В dwh такое слошь и рядом. Это хорошая практика

т.е. без бэкапа или репликакции совсем-совсем никак?? А переносом файлов tablespace ничего не добиться? Это было бы наиболее быстрым и эффективным способом, согласитесь...

Ну я вот уже советовал FDW... но это для "сильных духом", да. Зато, потенциально, простой меньше...

Ну я вот уже советовал FDW... но это для "сильных духом", да. Зато, потенциально, простой меньше...

а что такое FDW, сорри незнаком с аббревиатурой?

а что такое FDW, сорри незнаком с аббревиатурой?

Foreign Data Wrapper https://www.postgresql.org/docs/current/static/ddl-foreign-data.html

Заюзай уже вертику

Тер бесплатно дают

Foreign Data Wrapper https://www.postgresql.org/docs/current/static/ddl-foreign-data.html

спасибо

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

Ну я вот уже советовал FDW... но это для "сильных духом", да. Зато, потенциально, простой меньше...

Либо так - https://www.depesz.com/2016/11/08/major-version-upgrading-with-minimal-downtime/ Простой ещё меньше.

что-то нетак

с самим постгре

Это для сильных духом и упоротых по самые помидоры по части рукоблудия и красноглазия. :)

А почему? Вроде, на первый взгляд, в FDW не видно ничего такого страшного...

буду сейчас это гуглировать

А почему? Вроде, на первый взгляд, в FDW не видно ничего такого страшного...

Лучше потренироваться на тестовой среде. Подвох кроется в случае, если что то пойдет не так

unsupported frontend protocol 0.0: server supports 2.0 to 3.0

вообще неясно, что оно хочет

Лучше потренироваться на тестовой среде. Подвох кроется в случае, если что то пойдет не так

ну, само собой, тренируемся на кошках. Спасибо!

А почему? Вроде, на первый взгляд, в FDW не видно ничего такого страшного...

Так непосредственно мигрировать таблицы Вы собираетесь? Если да, то как? ;) (Я подозреваю, что на основании FDW можно "сварить" что-то подобное по эффекту pg_logical, но зачем?)

Еще один оффтоп. В сфере DBA бывают удаленные вакансии для джуниоров? Это вообще популярно? ? Я тут уже скучаю по большим хранилищам

Так непосредственно мигрировать таблицы Вы собираетесь? Если да, то как? ;) (Я подозреваю, что на основании FDW можно "сварить" что-то подобное по эффекту pg_logical, но зачем?)

Ага, есть же готовый механизм)))

Так непосредственно мигрировать таблицы Вы собираетесь? Если да, то как? ;) (Я подозреваю, что на основании FDW можно "сварить" что-то подобное по эффекту pg_logical, но зачем?)

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

Еще один оффтоп. В сфере DBA бывают удаленные вакансии для джуниоров? Это вообще популярно? ? Я тут уже скучаю по большим хранилищам

Это редкость. Удаленщикам не разработчикам не очень много плптят

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

А вот мы Вам тут насоветовали... а цель-то у Вас какая? Какие преимущества Вы рассчитываете получить?

А вот мы Вам тут насоветовали... а цель-то у Вас какая? Какие преимущества Вы рассчитываете получить?

ну, это на перспективу. Какой-то микросервис просядет по производительности из-за БД — я его БД перенесу на другой сервер. Типа того.

По моему проще искать узкие места и их решать. Я бы не решилась так дробить базу ?

ну, это на перспективу. Какой-то микросервис просядет по производительности из-за БД — я его БД перенесу на другой сервер. Типа того.

Хмм... был бы это отдельный PostgreSQL-кластер (с одной базой) для каждого клиента, всё было бы куда проще. Но у Вас их слишком много, наверное. :(

По моему проще искать узкие места и их решать. Я бы не решилась так дробить базу ?

это будет последним шагом после всего этого

Хмм... был бы это отдельный PostgreSQL-кластер (с одной базой) для каждого клиента, всё было бы куда проще. Но у Вас их слишком много, наверное. :(

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

ну, это на перспективу. Какой-то микросервис просядет по производительности из-за БД — я его БД перенесу на другой сервер. Типа того.

А какая версия PostgreSQL, кстати? В 10-ке Вам, может быть, хватит и встроенной логической репликации.

А какая версия PostgreSQL, кстати? В 10-ке Вам, может быть, хватит и встроенной логической репликации.

Десятка, да

Десятка, да

Тогда Вам стоит на неё посмотреть, скорее всего.

Тогда Вам стоит на неё посмотреть, скорее всего.

да, попробую. Большое спасибо!

unsupported frontend protocol 0.0: server supports 2.0 to 3.0

Это сильно похоже на кривого клиента (или проблемы с сетью). (Насколько я помню, версия протокола передаётся в startup packet при установлении соединения.)

Это сильно похоже на кривого клиента (или проблемы с сетью). (Насколько я помню, версия протокола передаётся в startup packet при установлении соединения.)

рестартнул сервер

и пробую еще раз

По моему проще искать узкие места и их решать. Я бы не решилась так дробить базу ?

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

А почему? Вроде, на первый взгляд, в FDW не видно ничего такого страшного...

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

Это редкость. Удаленщикам не разработчикам не очень много плптят

Да и разработчикам не вот уж. Чутка получше, чем по конкретному региону, но не более того.

Еще один оффтоп. В сфере DBA бывают удаленные вакансии для джуниоров? Это вообще популярно? ? Я тут уже скучаю по большим хранилищам

В эксплуатации вообще, и не только у ДБА, и не только у джунов, в России - это редкость редкостная, что аж плакать хочется. Вынь и положь манагерам чучелко эксплуатирующее в офисе. Повбывав бы!

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

Что такое чудовищно много? На моей памяти многотеррабайтную базу не дробили

Хм... Погорячился, виноват, исправляться не буду, ибо что выросло, то выросло. :) Помимо объёмов данных, есть ещё количество одновременных подключений. И логика работы. Когда данные слабо связаны и легко и непринуждённо разносятся по различным инстансам, то для увеличения отзывчивости БД, почему бы их не разнести? (я таки про количество клиентов не рекомендую забывать).

Когда случается автотранзакция (в случае когда запрос без BEGIN COMMIT) у нее какой уровень изоляции?

Microsoft SQL Server, PostgreSQL и Oracle - read commited

по умолчанию

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

Когда случается автотранзакция (в случае когда запрос без BEGIN COMMIT) у нее какой уровень изоляции?

Тот, который установлен в "default_transaction_isolation". По умолчанию — RC.

Microsoft SQL Server, PostgreSQL и Oracle - read commited

А Вы, к слову, не знаете (просто любопытно), в Oracle это настраивается?

По крайней мере хинт можно сделать

По крайней мере хинт можно сделать

И всё? Более-менее "глобальной" настройки нет?

В оракл вроде есть, но не помню точно. Обычно для оракла юзаю хиниы

Погуглировать попробуйте

Да ну, мне просто было любопытно — может, кто сходу знает. ;)

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