Владимир

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

Практический пример - весьма нагруженный веб сайт на кластере серверов:
два балансера с vrrp (keepalived)
четыре веб сервера nginx+php
два бд сервера mysql, между ними репликация мастер мастер, 1ый сервер под нагрузкой, 2ой в резерве.

Если мне надо обновить ядро или по каким либо причинам вывести из работы любой из серверов, для примера возьмем 1ый сервер.
То я просто на балансере меняю ип текущего активного бд сервера, - это изменение никак не скажется на работе сайта, после проверяю что все запросы уже выполняются на 2ом сервере(некоторые долгие запросы могут выполнятся до 10 секунд и нужно дождаться их выполнения чтобы их результаты попали на 2ой сервер).
После можно остановить mysql на 1ом сервере и проводить тех работы обновления и тд.

После тех работ я запускаю mysql на 1ом сервере и он сам синхронизируется с 2ым до актуального состояния.
когда синхронизация завершена - добавляю на балансере 1ый сервер как резервный.

1 увы не подскажу
2 зависит от интенсивности работы с базой, если много инсертов, апдейтов и удалений то и логов будет много
3 нужно настраивать в my.cnf max_binlog_size и expire_logs_days
4 эмм....
а) штатно мастер извещает слейва о том что чтото изменилось и слейв начинает вычитывать бинлог мастера пока он не закончится, и так по кругу
б) про 12 реплик первый раз слышу, вот прямо сейчас продакшен: mysql Server version: 5.5.46-log MySQL Community Server (GPL)
20+ слейвов с него делают репликацию
в) наверно вы про полу синхронную и асинхронную репликацию, по умолчанию репликация асинхронна и слейв может отставать от мастера по разным причинам ( небыло связи или слейв неуспевает изза перформанса за мастером и тд. ) но на мастера это никак не влияет.
но можно настроить чтобы мастер обязательно ждал потдверждения о том что слейв тоже выполнил изменения, но этот режим имеет много особенностей поэтому если вы незнаете зачем он вам то он вам точно не нужен, да и зачастую проще использовать тогда уже галера кластер.

на слейве какое у вас значение innodb_flush_log_at_trx_commit ? 0 ставили или опасаетесь ?
slave_parallel_workers используете ?

я никоим образом не разработчик но возможно вам помогут такие инструменты.
1 если много записей в базу а чтений на порядок меньше то посмотрите на движок TokuDB от Percona
2 также можно построить архитектуру вокруг брокера сообщения например rabbitmq в нем будут очередя для разных вещей - новые задачи с саайта идут в чередь оттуда их забирает скрипт и запускает воркеров который выполняют задачу, состояние задач и резльтаты воркеры могут тоже класть в другие очередя, а оттуда их уже забирать на сайт в базу или еще куда. Зачем это вобще нужно ? - Очередя задач и данных это буфер который позволяет размазать нагрузку во времени. Например результаты пишутся не напрямую в базу а сначала в очередь, а на сервере базы воркер читает очередь и кладет данные в базу при этом мониторя нагрузку на базу и недопуская оверлоада.

Мы у себя не мониторим нагрузку сайтов или юзеров (на шаред серверах) - каждому юзеру в его микроконтейнере выдано некоторое колво цпу/памяти/ИО в соответсвии с тарифом и все.
Мониторится же доступность сервисов на сервере и классические нагрузка на цп,/использование памяти и тд, в случае аномалий идем, смотрим, разбираемся что и почему.

Это общая ошибка о том что соединится с mysql не удалось по тем или иным причинам, вероятные варианты:
1 mysql занят - висит и не отвечает
2 первышено значение max_connections
3 mysql незапущенн или перезапускается после краша/сегфолта

Рекомендации:
1 во время проблемм выполнить в консоли mysqladmin pr (правда если mysql совсем плохо может тоже неработать)
2 включить логи mysql и посмотреть что там будет во время проблемv
3 настроить мониторинг mysql при помощи zabbix/cacti/munin/whatever (нужны графики колва соединений и чем собственно mysql занят)

поставте в my.cnf innodb_buffer_pool_size = 8G
также стоит смотреть во время нагрузки что происходит mysqladmin pr
- какие запросы долго исполняются и в каком они стотоянии.
таже есть тулза https://raw.githubusercontent.com/major/MySQLTuner... но это тоже не серебрянная пуля. применяя ее советы будте готовы что может стать хуже. делайте бекапы конфигов.

смотрите на утилизацию дисковой подсистемы,
если с дисковой проблемы то в top будет видно что много cpu wait
еще можно включить iostat -x 3 и смотреть в реалтайме нагрузку во время выполнения запросов.

Если интересует база данных самой цпанель(аккаунты, настрйоки, и все все все) то в mysql этого нет, в mysql только пользовательские базы и вспомогательные базы типа eximstats и cphulkd.
Ничего глобального для работы самой админ панели в mysql нет, цпанель фунционирует даже если mysql крашнулся.

Текущие настройки рейд контроллера смотрятся утилитой в зависимости от проивзодителя рейд контроллера
MegaCLI, arcconf, TW cli и такдалее.

При наличии 4х хардов рейд 10 самое оптимальное решение. незабудте настроить мониторинг состояния рейд масива.

количество процессов php-fpm резко возрастает,

в данной ситуации это нормально - они ждут соединения с MySQL но там уже превышенн лимит соединений.

Очень похоже что один из плагинов вордпресса по какимто причинам после выполнения запроса не закрывает соединение с mysql, сам вордпресс по умолчанию не использует постоянное соединение так что нужно смотреть в сторону плагинов и их конфигов.