Melkij

curl 127.0.0.1 -I

melkij@melkij:~$ nc -l 8081
HEAD / HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: curl/7.64.0
Accept: */*

curl 127.0.0.1:8081 -i

melkij@melkij:~$ nc -l 8081
GET / HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: curl/7.64.0
Accept: */*

И что мешает веб-серверу на разные запросы реагировать по-разному?

как правильно обеспечить надежность и безотказность ее работы?

Использовать адекватное железо и не мешать базе работать шаловливыми ручками.

доступен 24 часа 7 дней в неделю.

бекап

Объясните, пожалуйста, как это по вашему мнению между собой связано?
Бекапы необходимы, но как они связаны с высокой доступностью?

в случае проблем с доступностью, перезапускать/запускать саму СУБД.

Простой вопрос: зачем?
Если база сложилась и даже не смогла подняться самостоятельно - значит проблема капительная и разбираться надо детально. Рестартом по кругу вы можете скорее сделать совсем плохо, чем что-либо починить.
При том обычно проблемы начинаются от того что разработчики выкатили новую версию приложения и та начинает делать что-то странное. Например, забыли сделать индекс на 50гб табличку и засунули запрос с поиском по ней на главную сайта. Рестартом базы это, разумеется, не исправляется. А делает только больнее.

Многолетней давности pg_postmaster_start_time() впечатлять не буду - мы периодически ставим минорные апдейты на свои базы. И вам тоже весьма рекомендую обновиться до 10.7 или лучше уже на следующих выходных сразу до 10.8.

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

какие операции, запросы или их комбинации нежелательны для БД и могут привести к проблемам.

Большая часть инцидентов с недоступностью сервиса с точки зрения приложения - про уровни блокировок. Кто-нибудь попробует сделать create index вместо create index concurrently и привет ожидание блокировки на всю запись в таблицу. Большинство форм alter table сюда же, но они и чтение заблокируют.

а) никто из них не прячется? А работают так, как будет накрутка и щёлкание -- это в порядке вещей?

А зачем им прятаться? Ничего противозаконного не делают.
Нарушение правил использования сервиса - это не противозаконное деяние, а всего лишь нарушение правил сервиса. И именно этот сервис может по своему усмотрению как-то бороться. Если захочет.

б) почему некоторые всё-таки закрываются?

Например клиентов стало меньше доходности этого сервиса. Что там с инстаграмом - не имею представлений.

в) принимаю оплату через, например, яндекс деньги. Разве для Яндекс Денег приём оплаты от таких сервисов - законен?

Да, законен.

Получается **все** из них работают просто пока работается

Вообще все работают просто пока работается. Включая те же самые доски объявлений, если сервис убыточен - его закроют.

У конструкторов типичный workload - около нуля на большинство площадок и небольшой процент активных. Заворачивать индивидуально каждого в свою БД - сильно утомительно в поддержке. Дожили до 1000 созданных сайтов (что не так уж много если не сказать "вообще крохи") - у вас 1000 баз, что уже весьма дофига. Выкатить в прод новую версию приложения - уже приключение.

Если вы хотите SaaS - т.е. у конечных пользователей прямого доступа в БД нет никакого - то в поддержке сильно проще будет классическая схема шардирования. К тому же у вас данные разных клиентов заведомо по предметной области никак не пересекаются.
- в таблицах специфичных для клиентов вводится site_id и входит в уникальные ключи и прочее счастье ограничений целостности (для postgresql можете дополнительно прикрутить row level security и база будет дополнительно приглядывать)
- отдельно размещается ваш биллинг и управление пользователями, где помимо прочего пишете таблицу соответствия, какой site_id расположен на каком физическом хосте и в какой базе данных (плюс список ro-реплик)
- закешировать соответствие сайта базе можно в каком-нибудь redis и ходить с одного единого пула серверов приложений что сильно проще по масштабированию приложения (если сервер приложения рассматривать как stateless, что опять же сильно проще в поддержке).

В итоге схема позволяет работает с осмысленным числом крупных баз (начиная с одной и вводя новые по необходимости), неактивные сайты мигрировать в архивные базы, горячие от дорогих клиентов - выделять хоть даже в отдельную инфраструктуру. Кстати, фокус с отделением vip-клиента в отдельную инфраструктуру позволяет дать этому клиенту и прямой доступ в базу при необходимости и возможность пилить кастомный функционал именно для него.

Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.

Максимум != общая продолжительность теста.
https://httpd.apache.org/docs/2.4/programs/ab.html
Читайте внимательнее описания опций.

Конечно, Макконнелл "Совершенный код",
Мартин "Чистый код"
"Рефакторинг" Фаулера

"Приемы объектно-ориентированного проектирования" Э. Гамма

Поскольку в списке mysql - High Performance MySQL обязателен к прочтению
Отдельно рекомендую "Регулярные выражения" Дж.Фриддла, отлично вправляет мозг по регуляркам.

По базам в целом:
короткая "Architecture of a Database System" J. M. Hellerstein, M. Stonebraker and J. Hamilton расскажет об общих подходах построения СУБД
Bill Karwin SQL_Antipatterns - как не надо писать SQL. А вот, кстати, отличный материал как надо писать, но не книга: use-the-index-luke.com

Это всё вполне можно читать в порядке отдыха.

Фундаментальные, которые уже идут заметно тяжелее:
"Transactional Information Systems" Weikum, Vossen - монументальная теория транзакционной обработки
"Алгоритмы. Построение и анализ" Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн - про основные алгоритмы. Всё библиотечное, но полезнейшая весь для понимания обычно скрытой машинерии и для прохождения собеседований.

Капча лишняя по своему определению. Мешает, раздражает и никак не упрощает жизнь пользователя.
И лишь вынужденное зло для отсева наиболее глупых ботов.

Ведь легко можно написать скрипт, какой регистрируется сразу сотню левых аккаунтов на сайте, не успел оглянуться, и бд уже в ботах.

И пусть. Нормально сделанной базе плюс-минус лям пользователей - не вопрос.

Тоже самое с комментариями, легко сделать скрипт чтобы оставлял с разных ботов в разных топиках комментарии с рекламой.

С этим сложнее. Если есть пользовательский контент - то сначала необходимы люди, которые будут его модерировать (не забудьте сделать внятный инструмент модератора для поиска и удаления пачкой комментариев по шаблону). Антиспам автоматика не исключает необходимости в людях, которые будут проверять вручную. Вы видели спам на stackoverflow? А попадается и там.
И капча, разумеется, не панацея тоже.

insert_id будет неправильный

Невозможно. На любой интенсивность записи. Значение last insert id сессионное, а не глобальное.

Оберните в транзакцию - тогда до коммита никто и не увидит частично записанную транзакцию. Если говорить о транзакционных вещах, конечно, а не каких-нибудь myisam.

Это автоматическая отписка от саппорта и ничего делать (даже проверять) они не намерены.
Нам как-то коммерческий сервис забанили без причины. Удалось обратить на себя внимание только после официального бумажного письма от организации. По другому на контакт никак не шли.

Если проект не наколеночная поделка одного человека за пару вечеров - то структура БД живёт непосредственно рядом с проектом и накатывается через миграции. Ну, например, описание у Yii2: www.yiiframework.com/doc-2.0/guide-db-migrations.html

$_POST существует всегда. Ну разве только вы сами руками unset сделаете.
Поэтому проверять на isset($_POST) не имеет смысла.

то в файл приходит:

Значит именно этот мусор вам и отправляют. Вместо нормально кодированного application/x-www-form-urlencoded. Пинайте разработчиков этого сервиса, чтобы исправили этот идиотизм.

Ну или пишите парсер-костыль.

insert into tablename (datetimefield /*other fields*/) 
    select now(), /*other fields*/ 
    from (select 1) anyonerow 
    where not exists(
        select 1 from tablename where datetimefield >= now() - interval 1 hour
    )

Результат была ли запись добавлена - смотреть в affected_rows.

pdo::query false вернуть может в одном случае: у вас PDO::ATTR_ERRMODE установлен в неверное значение. Установите его в нормальный PDO::ERRMODE_EXCEPTION.

nginx.org/en/docs/http/ngx_http_geoip_module.html
В приложении читать из $_SERVER.

В тегах apache указан - с ним отдельно посмотрите, есть ли особенности передачи заголовков от nginx'а или сразу заработает.

В смысле с заголовками?
Тело POST-запроса - это именно php://input
Что отправили, то тут и получите.