Например для postgresql это будет в корне неверное решение и ничего хорошего из этого не получится.
Сильно зависит от устройства конкретной СУБД, т.е. да - вопрос к DBA.
сложности со сложными условиями в следствии ограничений GET (в том числе и на длину в 255 символов).
это из какого RFC?
Интересуюсь потому, что в стандартах на http этого не находил, а лимиты сверху есть у конкретных реализаций: браузеров и веб-серверов.
посмотрите детали на 4 консоли или повторите команду на 2 или 3 консоли вручную. Возможно необходимо сделать специальный bios_grub раздел (parted умеет такую метку, например) или сделать отступ первого сектора раздела побольше от таблицы разделов.
там скорости передачи повыше, и могут в отличии от SATA достигать 2-3гигабит в секунду.
SATA II - это уже до 3 гбит/с на интерфейсе. SATA III - до 6гбит/с
M.2 - это до 4 линий PCI-E 3.0, чуть меньше 4 гигабайт в секунду предел, не гигабит.
Ну а дальше вопрос к контроллеру и типу нагрузки. Последовательная передача давно уже упирается в SATA интерфейс.
Повторюсь: обычно используются оба одновременно. pg_dumpall -g для глобальных данных кластера и отдельно pg_dump для сохранения снимков отдельных базы, которые надо бекапить. Раскатывается при необходимости соответственно в обратном порядке, сначала глобальные данные из pg_dumpall -g, затем из снимков pg_dump в нужные базы сами данные этих баз.
pg_dumpall в чистом виде использовать тоже можно. Но если вам понадобится восстановить отдельную табличку - это будет несколько неудобно.
Как уже упомянул - посмотрите patroni.
О pacemaker коллега отзывался как о довольно сложной штуке где легко ошибиться и надо много тестировать свои конфиги, про repmgr - как штука может и неплохая, но с довольно печальной документацией.
От вас зависит. Нужен вам балансировщик или нет, если нужен то что и как балансировать. Нужны вам 3 реплики или два кластера мастер+реплика - тоже мне неизвестно.
Пулер коннектов - обычно нужен. Типично pgbouncer в transaction mode локально на каждой машине с базой.
Если у вас не сохранён ВЕСЬ PGDATA, включая все файлы и всё по симлинкам - то база разрушена и нормально не стартует уже никогда. Ненормально тоже не стартует.
$PGDATA/base - это не рабочий каталог. Рабочий каталог - это $PGDATA целиком.
А так - ничего сказать нельзя, возможно ли достать хоть что-нибудь хоть в каком виде. Можно попробовать resetxlog дёрнуть или к pg_filedump и исходникам приставать.
Например для postgresql это будет в корне неверное решение и ничего хорошего из этого не получится.
Сильно зависит от устройства конкретной СУБД, т.е. да - вопрос к DBA.