Melkij

Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как 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 (возможно по отдельному сканированию на каждую строку, которая вызвала проверку целостности ключа)

Потому что верное описание синтаксиса limit дано в первой статье.
Что проверяется первоисточником https://dev.mysql.com/doc/refman/8.0/en/select.html

[LIMIT {[offset,] row_count | row_count OFFSET offset}]

Формируется выборка из row_count + offset числа строк, затем первые offset строк отбрасываются и в результирующий набор попадает не более row_count строк.

Без явно указанного order by выборка смысла не имеет вообще, СУБД по стандарту имеет право отдавать любые удовлетворяющие запросу данные в любом порядке по своему усмотрению. Соответственно offset будет взять непонятно откуда и непонятно как.

Есть у меня один зомби-процесс

Где?

user 3954 0.0 0.0 105316 952 pts/0 S+ 05:57 0:00 grep -w Z

Здесь нет ни одного зомби.

А grep в списке процессов ожидаемо есть и по условию "встречается Z" он успешно находит самого себя.