Снимать файловый бекап при запущенной базе можно. Это делают все серьёзные утилиты бекапа postgresql: pgbackrest, wal-g, barman и прочие. Но для этого нужно соблюдать правила, которые требует сама база. К внимательному прочтению. Вот если у базы не попросить потребные данные для файлового бекапа - то это к приключениям и бекап выполнен неверно.
Только в случае постгреса эти файлы не переносимы, развернуть их на другом сервере не выйдет.
Ограниченно переносимы.
Развернуть на подходящем сервере выйдет. Это просто частный случай настройки потоковой репликации. Копируется именно физический PGDATA, а не логический дамп.
Основные ограничения: совпадение критичных для бинарной совместимости флагов компиляции. Сюрприз, даже другая аппаратная архитектура может не быть препятствием. Мы однажды с amd64 на arm64 перевозили базу физической репликацией даже.
я бы предложил сперва в MPTCP потыкаться, чем с агрегированием туннелей. Всё равно нужен гейт в обычную сеть, но по крайней мере MPTCP проектировался под такое использование.
В интерфейсе админа домена должен быть включен IMAP.
У каждого имени пользователя должен быть включен IMAP в своих настройках.
Пароль для IMAP - не пароль учётки в яндексе, а отдельный пароль приложения (на вкладке безопасности каждого пользователя)
По крайней мере так для меня с mbsync в новое место. Я не организация на сотню сотрудников, а одно физическое лицо со своим личным доменом.
Александр Борисович, sudo apt install postgresql-15 . Всё, что вы упрощаете вкорячивая в этот элементарный процесс докер, кроме привнесения дополнительный проблем?
ничего подобного, обычный alter type .. add value для добавления значения в enum, самый обычный alter table ... set default для значения по-умолчанию как для всех прочих типов данных.
какие софтварные пределы, вы о чём? Простейшая полностью логичная идея оптимизации задачи: прочесть блок с одного диска и отправить на запись из памяти на несколько дисков параллельно вместо многократного чтения диска-источника.
а топологию подключения дисков можно обсуждать, когда вопрос будет про поиск источника замедления при одновременной записи нескольких десятков HDD. Я так понял, даже упомянутые выше 15 дисков не планируется подключить одновременно, куда там упираться?
покажите мне HDD, который способен упереться в полосу не то что SATA III, а хотя бы SATA II.
но да, общий процесс записи будет болтаться на уровне возможностей самого медленного из дисков. Но по времени это всё равно существенно быстрее, чем копировать каждый диск в отдельности. Время X записи самого медленного диска никуда не денется, как его не переставляй.
вы не можете просто так взять один hdd на 500гб и один hdd на 320гб и получить функционирующий raid1 на 500гб. raid1 на 320гб получить в этом случае можно. Но вот позволит ли вам ваша реализация рейда использовать каким-то образом оставшиеся 180гб на 500гб диске - вопрос к конкретной реализации.
Так в спецификации RAID есть примерно 6 типов массивов. И не каждый из них ведь будет так делать.
отчего же? Эталонные raid, без разницы 0, 1, 4, 5, 6 или 10 уровня, предполагают именно использование идентичного объёма дисков в массиве. Меняется логика чтения, записи и гарантий сохранения данных, но используемый объём тома массива одинаков для всех участников.
Вот JBOD по своему определению допускает разного объёма диски, но что по этому поводу думает конкретная реализация - тоже вопрос.
Ограниченно переносимы.
Развернуть на подходящем сервере выйдет. Это просто частный случай настройки потоковой репликации. Копируется именно физический PGDATA, а не логический дамп.
Основные ограничения: совпадение критичных для бинарной совместимости флагов компиляции. Сюрприз, даже другая аппаратная архитектура может не быть препятствием. Мы однажды с amd64 на arm64 перевозили базу физической репликацией даже.