Melkij

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, дефолтно выключено.

Составной индекс b типа сравнивается кортежами, то бишь порядок определения индекса имеет значение

Зависит от алгоритма. Справедливо для btree, может быть полностью лишено смысла для других типов. Например, если СУБД будет строить ключ для hash-индекса от конкатенации полей индекса - (a,b) ничем не будет отличаться от (b,a).

лучше определять b индекс для столбцов с высокой селективностью

Не имеет важного значения.
Значение имеет под какие запросы индексы делаем. btree (a,b) не может нормально обслуживать where b = value and a > value, для этого запроса куда осмысленнее (b,a)
Если у вас запрос where a = const and b = const, то btree индексы (a,b) и (b,a) будут равнозначны.

Если у вас индекс с крайне селективным timestamp на первом месте - то что вы с ним делать-то будете? Строгое сравнение таймштампа случай крайне редкий, а на любой запрос диапазона эффективность последующих полей падает катастрофично и большинство СУБД их вовсе не используют. В основном используют только если получается взять индекс как покрывающий.

имеется два столбца в некоторой абстрактной таблице: x - внешний ключ, y - datetime

Варианты если вы попробуете сделать только btree(y,x) индекс:
- СУБД вовсе откажется делать FK т.к. нет подходящего индекса для проверки FK
- СУБД неявно этот индекс создаст при добавлении FK
- СУБД позволит существовать FK без индекса, но соответственно fullscan всей таблицы на каждую проверку консистентности по этому FK (возможно по отдельному сканированию на каждую строку, которая вызвала проверку целостности ключа)