Сергей Горностаев, не, ну почему сразу "не уважающая"? В стандарте просто нет join в update, никакого, только голый UPDATE одной таблицы. from в postgresql такое же собственное расширение синтаксиса как и returning.
А если проще задать вопрос, в каких случаях стоит заморачиваться с репликацией данных и pgpool?
pgpool - только если хотите чтобы было больно в эксплуатации. В общем не надо pgpool.
репликация через streaming replication - думаю мне хватит одной руки пересчитать базы (из нескольких сотен) где у production базы *нет* реплики. Хотя бы один hot standby нужен для любой важной базы.
Сергей Горностаев, fun fact: обычно поля timestamp форматирует именно сам postgresql, а результат так и пересылается текстом. Исключение: если клиент намеренно запросил передачу ответа в бинарном виде, тогда пересылается сырой int64 и это уже задача клиента корректно воспроизвести формат хранения.
от 2.17 до 2.27... хм, не помню, надо проверять. Но вероятность высокая - мне помнится в районе обновления ubuntu 14.04->16.04 тоже нужно было часть индексов перестраивать
вопрос-то останется "что с образом диска делать дальше". С зеркалом конечно проще, найти только offset начала файловой системы. Но это если там простое глупое зеркало, а не что-нибудь новомодное.
Всё равно для начала нужно понимать, с чем именно работаем.
если программный - то при чём тут "Rebuild в биосе"? Биос о программном рейде, конечно, ничего не знает и не его это дело, что там ОС дискам командует делать.
Единая точка отказа - это автоматика failover базы как таковая. Там где такое есть - число аварий возрастает, а не уменьшается. Не забудьте учесть хоть как-нибудь в планах риски дополнительных аварий по причине именно добавленного autofailover. А так же сопутствующей возросшей сложности администрирования. Я предупредил.
