Melkij

man ssh
ssh ... -i /path/to/private_key

mysql не умеет конвертировать значения при смене типа на несовместимый.
Поэтому необходимо добавить новое поле, обновить всю таблицу, удалить старое поле и переименовать новое в старое.

Для конвертации из числового unixtime в datetime есть подходящая функция FROM_UNIXTIME, поэтому обновление таблицы будет таким:

update tablename set new_datefield = FROM_UNIXTIME(old_int_unixtime);

Зависит от требований к бекапам.
Если нужен point in time recovery, т.е. возможность восстановить состояние кластера на какую-то произвольную транзакцию - то это pg_basebackup + архив WAL.
Чтобы не собирать конструктор вручную - есть barman. Если бекапить хотите куда-то в s3 - то проще будут wal-e или wal-g
Одну базу в отдельности так бекапить и восстанавливать не выйдет, только весь инстанс целиком. Объём бекапа = объём всего инстанса + объём всех WAL от начала basebackup до нужного момента восстановления, количество wal зависит от вашей пишущей нагрузки.

Если достаточно логических слепков данных, например, ежесуточных - тогда да, pg_dump. Восстановление соответственно только на момент начала снятия дампа.
Типично делается pg_dumpall -g для сохранения глобальных данных кластера - пользователей, tablespace, имён баз и отдельные pg_dump для тех баз которые надо бекапить.
Формат часто custom делается, т.к. он штатно сжимается и позволяет через pg_restore восстанавливать определённые объекты из дампа, а не только всё целиком как текст через psql. Для гигабайтной базы смысла нет, а для баз побольше имеет смысл делать формат directory в несколько потоков.

Разница в количестве вопросов. Вернее в приоритете этих вопросов. How the Installer Works, только параметром priority отличается эти пункты меню.

Для цели резервного копирования вам нужна не вторая база, а само резервное копирование. То есть pg_basebackup и архив WAL с момента старта basebackup до момента на который вы хотите восстановить состояние базы. Посмотрите barman как более готовую штуку для этого. Или wal-e/wal-g, которые проще в настройке сами по себе - если вы бекапитесь куда-нибудь в совместимое с ними место.

Если вам нужно не резервное копирование, а запасная машинка на случай проблем с первой - то вам нужна репликация. Штатная потоковая репликация отличная стабильная штука. Надо пояснять чем отличается резервирование от бекапов?

Писать кодом в две разные базы - как раз идея плохая как для резервирования, так и для бекапов. Записали изменение в одну базу, во вторую не смогли с какой-нибудь мелкой ошибкой вроде сети моргнувшей. Что делать будете? А ничего хорошего. Корректно писать в несколько мест - задача не слишком тривиальная и нужно что-то сочинять, например протокол двухфазного коммита.

Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как CAP теорема, весьма мешающая сделать серебряную пулю.

Ладно, ближе к делу.
Самая большая проблема с автоматическим failover СУБД - решить, что уже пора переключаться. Для чего необходимо выяснить, а что вообще происходит, не развалилась ли сеть, не вернётся ли через пару секунд мастер обратно - если в сети в результате окажется два мастера, то нет никакого разумного способа определить, где данные актуальны. Худшее что можно представить - это split brain: когда часть приложений ходит в один мастер, часть в другой и данные стремительно расходятся в разные стороны. Есть такая байка про гуглдиск "у нас всё отказоустойчиво, все данные хранятся в 4 экземплярах. Правда, у нас была авария и мы теперь понятий не имеем, какая из копий актуальная"
Переключение мастера на 90% - решение административное и человеческое. Автоматика же добавляет головной боли. Зачастую - больше головной боли, чем без неё. Особенно если железо адекватное серверное, которое "вдруг" выпадает очень редко.

Обычно автоматики нет, и есть детальная инструкция по переключению мастера БД, по которой и в ночи можно переключиться.

Если всё ещё хочется походить по граблям - посмотрите patroni. Есть пара кластеров с ним на поддержке, при наличии мониторинга особых проблем не припоминаю. До split brain по крайней мере не придумал как довести, вроде все варианты прикрыты. В худшем случае в readonly уходит.

Ошибка в используемой библиотеке. Так запрашивать версию базы нельзя.

Ломается именно на 10 очевидно из-за смены политики нумерации, до 10 было x.y.z, где x.y - major версия, начиная с десятки релизы нумеруются x.y, где major версия только первая цифра. Глупый код пытающийся распарсить номер находит не то что ожидает.

Вероятно, полтора года спустя с релиза postgresql 10.0, библиотеку уже исправили. Хотелось бы надеяться что на использование специально для этого предназначенной current_setting('server_version_num'), а не опять костылём вокруг не предназначенной для того version()
Копать соответственно в сторону обновления версии библиотеки. Если никак - откатываться на postgresql 9.6.

Если curl_exec вернул управление и не выставил curl_errno - значит запрос выполнен.

Между состояниями "запрос выполнен" и "загрузилась страница" - разница как между колесом и машиной. Необходимо уточнение что такое "загрузилась страница".

Я изучал эту пару:
"The C Programming Language" Dennis Ritchie, Brian Kernighan
"2lst Century С" Ben Klemens

Но важная оговорка - я полез в C уже имея многолетный опыт разработки на других языках. Обе книги весьма затруднительно назвать учебниками для начинающих.

Нужен explain (analyze,buffers), сильно желательно с track_io_timing = on в конфиге.

параметр work_mem на данный запрос не может оказывать почти никакого влияния

Оказывает. Если планировщик решит, что work_mem не хватает - не будет hash join. Для сортировки 27кб, очевидно, без разницы.

Впрочем, зачем вам вообще join подзапроса где одна только группировка подзапроса занимает половину времени ответа? Вам простой exists нужен.

SELECT "t1".* FROM table_1 as t1
where exists (select 1 from table_2 as t2 WHERE t1.primarykey=t2.session)
ORDER BY "starttime" DESC LIMIT 20;

А дальше know your data. Если по starttime DESC быстро находятся нужные exists - будет хорошо. Если exists мало - стоит подумать, а не денормализовать ли этот признак в table_1 с триггером для консистентности в table_2 и частичным индексом по starttime where t2_exists.

Поля session и primarykey в формате uuid

Не очень хорошая идея. Оно и сильно медленнее при сравнении относительно bigint (особенно если речь о varchar, а не uuid типе данных) и из-за случайного распределения несколько сбивает с толку статистику планировщика.

Формат условия "функция(поле_таблицы) оператор" в принципе не может использовать индекс по этому полю. Если нет других селективных индексов - гарантированный fullscan.
Формат условия "поле_таблицы between ? and ?" - может использовать индекс.

Выводы?
3 диапазона через or или, возможно, эффективнее будет 3 union all в каждом по одному диапазону. Не помню насколько адекватно нынче mysql ведёт себя с or.

Нет, не имеет. Планировщик запроса с таким разберётся самостоятельно.

Поскольку меня сюда призвали, то напишу пару слов.

Если вы ещё не доросли до отдельной железки под базу - то для базы не будет принципиальной разницы какой гипервизор у вашей виртуалки. Интереснее вопрос насколько честен хостер (уточняйте отдельно, я с хостерами не знаком).
openvz заметно легче для хостера по ресурсам и позволяет легко продавать ресурсов сильно больше чем у него есть в действительности.
С kvm - сложнее заниматься оверселлом хотя бы по памяти, хотя помнится даже там можно.

С openvz у вас будет на порядок меньше возможностей настройки, т.к. ядро используется хост-системы и никто не даст вам его трогать. И весьма старое ядро, кстати.
На kvm соответственно полноценная виртуальная система. Можете ставить что угодно и как угодно тюнить ядро. Если хостер уважает себя и предоставляет virtio устройства - то это и работать будет внятно.
mysql запустится и там и там. Краеугольный для любой СУБД вопрос производительности дисков и там и там от вас полностью скрыт и зависит от хостера.

Универсального ответа нет. Если вы под базу не настраиваете ядро, то возможно и openvz подойдёт, обычно там предлагают больше ресурсов за те же деньги.

Мой ответ про докер же относится именно к докеру. Если вы можете пробросить директорию хост-системы в докер - почти наверняка у вас уже своя железка или vps и вы пытаетесь именно добавить ещё прослойку. Если вы захотите на своей vps ещё вдобавок запихать бинарники базы в докер - тогда будет вопрос "зачем". Если вы хотите имея отдельную железку только под базу запихать эту базу в виртуалку - тогда будет вопрос "зачем".
Если у вас нет железки - то vps очевидно дешевле чем аренда целой железки и за счёт этого вполне целесообразно рассматривать аренду виртуалки.

lastInsertId (ака LAST_INSERT_ID функция mysql) безопасен для конкурентного доступа, возвращает сгенерированное значение auto increment для предшествующего запроса именно в этом соединении.

Поэтому если вы в одном соединении делаете insert, то последующий lastInsertId через это соединение гарантированно вернёт корректное значение.

Всё ему нравится,

согласованное состояние восстановления достигнуто

начало передачи журнала с главного сервера, с позиции 4A4/E000000 на линии времени 2

База запустилась, репликация запустилась, всё работает.

А вот вам, наверное, не нравится то что база не принимает read only коннекты? Проверьте настройку hot_standby в postgresql.conf, дефолтно выключено.