WordPress для многих проектов давно перестал быть «блогом на PHP». Это лендинги с рекламным трафиком, интернет-магазины, большие контентные проекты. К такому сайту тут же прилетает бизнес-требование: «чтобы работало всегда». Значит, пора говорить не только о кешировании, но и о высокой доступности: wordpress ha, отказоустойчивые PHP-узлы и база данных с репликацией или кластером Galera.
В этой статье разберём, как построить отказоустойчивую схему WordPress на VDS без Kubernetes, с классическим стеком: Nginx/HAProxy, PHP-FPM, Redis и MySQL/MariaDB (Galera или репликация). Посмотрим архитектурные варианты, плюсы и минусы galera cluster против mysql replicas, а также типичные грабли.
Когда вообще нужен wordpress ha
Не каждый сайт обязан жить в HA-архитектуре. Для начала полезно честно ответить на два вопроса: сколько стоит простой и насколько критична потеря пары минут данных.
Практически WordPress с высокой доступностью нужен, если:
- На сайте крутится платный трафик, и отключение на час стоит дороже, чем пара лишних VDS.
- Это интернет-магазин: отменённые заказы, сломанная корзина и оплаты — прямые деньги.
- Есть пиковые нагрузки (распродажи, эфиры, новости), и один сервер периодически «ложится».
- Сайт — часть внутренней инфраструктуры (портал, документация), и простой блокирует процессы.
Если же это небольшой сайт-визитка с десятком лидов в месяц, чаще выгоднее вложиться в хорошее кеширование и надёжные бэкапы, чем в сложную архитектуру php ha и кластер баз данных.
Базовая архитектура HA WordPress на VDS
Рассмотрим классическую трёхслойную схему:
- Слой балансировки и SSL-терминации (Nginx или HAProxy).
- PHP-серверы (Nginx + PHP-FPM) — несколько узлов.
- База данных + Redis (кеш и сессии).
Минимально жизнеспособный набор для wordpress ha может выглядеть так:
- 2 VDS с Nginx/HAProxy (L4/L7 балансировка, SSL, статика).
- 2–3 VDS с Nginx + PHP-FPM (backend для WordPress).
- 3 VDS под кластер MySQL/MariaDB (Galera) или мастер и 2 реплики.
- 1–2 VDS под Redis (репликация или Sentinel) — кеш, сессии, объектный кеш.
Отдельно надо решить вопрос с файловым хранилищем для загрузок (wp-content/uploads): NFS, синхронизация через rsync/lsyncd, S3-совместимое хранилище и плагин для offload’а.
Балансировщик и php ha
Цель слоя балансировки — распределять запросы по PHP-узлам и уметь пережить падение одного из них. Типовая связка:
- На краю — Nginx (или пара Nginx за виртуальным IP) для HTTPS и раздачи статики.
- Внутри Nginx — upstream на несколько PHP-backend’ов (Nginx + PHP-FPM на других VDS).
Самый простой вариант — DNS round-robin на пару фронтендов и Nginx с upstream-группой внутри, но куда надёжнее использовать внешний L4-балансировщик (например, отдельный HAProxy с VRRP/keepalived или балансировку, которую предлагает провайдер). Для более продвинутой логики по HTTP можно посмотреть в сторону HAProxy и наших разборов, например статьи про лимитирование трафика на stick-tables в HAProxy.
Балансировка HTTP и sticky-сессии
WordPress в идеале должен работать статически и кэшироваться, но в реальной жизни есть админка, корзины, личные кабинеты, плагинные формы. Здесь важны две вещи:
- Корректная обработка сессий (не теряем авторизацию при переключении между backend’ами).
- Здоровый бекенд при переходе пользователя между страницами.
Есть два основных подхода:
- Хранить сессии и PHP
session.save_handlerв Redis (или Memcached) — тогда любой backend может обслужить пользователя. - Включить sticky-сессии на балансировщике (по cookie или IP), чтобы один пользователь попадал на один backend.
Для настоящего php ha первый вариант предпочтительнее: если backend упадёт, запросы уйдут на другие узлы, и сессия не потеряется.
PHP-FPM: масштабирование и отказоустойчивость
Каждый PHP-узел представляет собой типичный LEMP-стек: Nginx + PHP-FPM, код WordPress синхронизируется через Git/CI, rsync или деплой-инструмент. Для высокой доступности важно:
- Единый способ доставки кода на все PHP-узлы (pipeline CI, hook в Git, Ansible и т.п.).
- Идентичный конфиг PHP-FPM:
pm,pm.max_children, лимиты памяти. - Мониторинг стейта: метрики по
status_path, healthcheck’и со стороны балансировщика.
При таком подходе потеря любого одного PHP-сервера не валит сайт: балансировщик просто перестаёт слать трафик на упавший узел.
База данных: galera cluster vs mysql replicas
На уровне СУБД вариантов два:
- Кластер Galera (MariaDB или Percona XtraDB Cluster) — синхронная репликация, multi-master.
- Классическая асинхронная репликация MySQL: один мастер, несколько реплик для чтения и резервного переключения.
У каждого подхода свои плюсы, минусы и нюансы эксплуатации в связке с WordPress. Подробный обзор Galera мы уже разбирали отдельно в статье про кластер MariaDB Galera для высокой доступности.
Galera Cluster: сильные и слабые стороны
Galera Cluster даёт ощущение «волшебного» HA: несколько узлов, любой из них можно использовать для чтения и записи, данные синхронизируются синхронно (по факту — почти синхронно, но с серьёзной гарантией целостности).
Плюсы Galera для WordPress:
- Потеря одного узла не приводит к недоступности базы, если есть кворум (обычно 3+ ноды).
- Записи и чтения могут идти на любой живой узел (удобно для балансировки).
- Нет сложной ручной пересборки репликации после переключений роли мастера.
Минусы:
- Нужна очень хорошая сеть между узлами: стабильная низкая задержка и достаточная пропускная способность.
- Оверхед синхронной репликации: при большом количестве записей задержки транзакций растут.
- Высокие требования к аккуратной настройке (SST/IST,
gcache, flow control, защита от split-brain).
Для WordPress большая часть нагрузки — чтение. Записей немного (посты, комментарии, заказы), поэтому по латентности Galera живёт комфортно, если не использовать тяжёлые плагины и не допускать постоянных массовых апдейтов.
MySQL replicas: мастер и ведомые
Классическая схема: один мастер, пара реплик. В терминах HA для WordPress это означает:
- Все записи и критичные операции идут на мастер.
- Чтения (SELECT) часть плагинов и кода могут направлять на реплики.
- При падении мастера вы вручную или автоматикой (Orchestrator, ProxySQL, custom-скрипты) переключаете одну из реплик в роль мастера.
Плюсы mysql replicas:
- Простота понимания и отладки: один источник истины, остальные — копии.
- Меньший оверхед по сети и задержкам, чем у синхронного кластера.
- Хорошо масштабируется на чтение — реплик можно сделать несколько и использовать для тяжёлых отчётов.
Минусы:
- Переключение мастера — отдельная задача (и, если автоматика не отлажена, момент риска).
- Асинхронность: возможна небольшая потеря данных при аварии, если реплика не успела получить последние binlog-записи.
- Для WordPress сложнее прозрачно раскидывать чтения и записи по разным хостам без плагинов и дополнительной логики.
Часто на практике выбирают такую стратегию: один мощный мастер, одна или две реплики; WordPress и большая часть плагинов работают с мастером, а реплики используются либо для внешних сервисов (аналитика), либо для асинхронных задач и бэкапов.
WordPress и отказоустойчивость базы на практике
Архитектура архитектурой, но WordPress сам по себе не очень «кластеро-осознанный». Есть несколько важных моментов, которые надо продумать заранее.
Подключение к БД и endpoint’ы
В идеале все PHP-узлы должны подключаться к БД через единый endpoint (DNS-имя или виртуальный IP), за которым стоит:
- либо балансировщик (например, HAProxy) с логикой маршрутизации чтения и записи и healthcheck’ами;
- либо кластерный VIP (keepalived) на узлах Galera или мастера и реплик.
Такое решение позволяет при переключении мастера (или при выводе ноды Galera из кластера) не трогать конфиги WordPress: для него всегда есть один «mysql.internal».
Автоматическое переключение и консистентность
С MySQL-репликацией классический подход — использовать внешний управляющий слой (Orchestrator, ProxySQL, свои скрипты), который:
- следит за мастером и репликами;
- в случае недоступности мастера продвигает одну из реплик;
- обновляет конфиг или backend-цель балансировщика.
Для Galera кворум и выбор мастера по сути встроены в сам кластер, но вам всё равно нужен уровень, который определяет, куда именно подключается WordPress (какой узел считать предпочтительным по задержкам и нагрузке).
WordPress и долгие транзакции
Крупные плагины (особенно e-commerce, membership, импортеры) могут держать долгие транзакции. В Galera это чуть болезненнее: узлы с долгими транзакциями могут блокировать репликацию и вызывать flow control. Поэтому важно:
- Следить за длительностью транзакций и медленными запросами.
- Выбирать плагины с адекватным SQL-профилем и избегать тяжёлых массовых апдейтов по расписанию.
Файлы и мультимедиа: самая недооценённая часть HA
База и PHP — это половина истории. Вторая половина — директория wp-content/uploads, а ещё иногда wp-content/cache и дополнительные директории, где плагины хранят файлы.
Основные варианты:
- Общий файловый ресурс (NFS/SMB/cephfs и т.п.) между всеми PHP-серверами.
- Синхронизация файлов (rsync, lsyncd, unison) между узлами.
- Вынос медиа в S3-совместимое хранилище и использование плагина offload’а.
Для настоящего wordpress ha на нескольких PHP-узлах лучше всего работает третий вариант: медиафайлы хранятся вне VDS, а фронтенд и админка обращаются к объектному хранилищу. Это снижает риски рассинхронизации и упрощает масштабирование.
Кеширование и Redis для стабильного HA
При многократном увеличении количества VDS неизбежно вырастает стоимость инфраструктуры. Чтобы сохранить запас по производительности без удвоения ресурсов, обязательно используем кеширование.
Типовая схема:
- Nginx на краю — microcache для анонимного трафика (несколько секунд) и долгий кеш статики.
- Object cache для WordPress (Redis) — резко снижает нагрузку на БД.
- Сессии и
transientsв Redis — для равномерной работы sticky/без sticky.
Redis при этом должен быть доступен всем PHP-узлам и сам иметь элементарную отказоустойчивость (реплика плюс Sentinel или хотя бы ручное переключение).
Минимальные конфиги: как это выглядит
Ниже не готовый production-конфиг, а скорее скелет того, как может выглядеть проксирование запросов Nginx с балансировкой на PHP-узлы и использованием upstream к кластеру БД (Galera или мастер).
Пример upstream-группы PHP в Nginx
upstream php_backends {
server 10.0.1.10:9000 max_fails=3 fail_timeout=30s;
server 10.0.1.11:9000 max_fails=3 fail_timeout=30s;
server 10.0.1.12:9000 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
server_name example.com;
root /var/www/example.com/public;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php_backends;
fastcgi_read_timeout 60s;
}
}
Подключение WordPress к единому endpoint БД
В wp-config.php достаточно задать один хост (например, DNS-имя балансировщика или виртуального IP):
define('DB_NAME', 'wpdb');
define('DB_USER', 'wpuser');
define('DB_PASSWORD', 's3cret');
define('DB_HOST', 'mysql-cluster.internal:3306');
Дальше задача балансировки и переключения между узлами БД ложится на внешний слой, а приложение работает с одним и тем же адресом.
Мониторинг, алерты и проверки здоровья
Сложная схема wordpress ha, php ha и кластера базы данных без нормального мониторинга превращается в лотерею. Минимум, что стоит контролировать:
- Доступность фронтенда: HTTP 200 или 301 с главной страницы, время ответа.
- Здоровье PHP-узлов: код ответа от тестового PHP-скрипта, метрики PHP-FPM.
- Состояние Galera или репликации: статус нод, лаг, состояние SST и IST.
- Задержки и ошибки Redis, размер кеша, ключевые показатели памяти.
Полезно завести отдельный healthcheck-эндпоинт, который проверяет подключение к БД, Redis и ключевые плагины, чтобы балансировщик мог быстро выводить из ротации узлы, где что-то сломалось.
Бэкапы в мире HA-WordPress
HA не заменяет резервное копирование. Более того, при сложной архитектуре растёт и риск ошибочных действий администратора, так что бэкапы становятся ещё важнее:
- Регулярный дамп БД (или инкрементальные бэкапы средствами СУБД) с проверкой восстановления.
- Резервные копии
wp-config.php, списка плагинов, тем и настроек. - Отдельное резервирование медиафайлов (если не используются внешние хранилища с собственной надёжностью).
Хороший тон — регулярно поднимать тестовый стенд из бэкапов и проверять, что сайт реально оживает, а не просто создаётся архив.
Типичные грабли при построении HA WordPress
Под конец — несколько ситуаций, которые на практике чаще всего бьют по HA-схеме WordPress на VDS.
- Рассинхронизация кода и конфигов. Если нет единого процесса деплоя, разные PHP-узлы постепенно расходятся по версиям темы, плагинам и настройкам.
- Локальные файлы в плагинах. Некоторые плагины пишут временные файлы или кеш на локальный диск. В многозадачной схеме это приводит к непредсказуемым багам.
- Небрежное обращение с транзакциями. Гладко работающее на одном MySQL решение в Galera-кластере может начать блокировать репликацию из-за длинных транзакций.
- Отсутствие тестов на отказ. HA-схема не считается настроенной, пока вы хотя бы раз не отключили вручную одну из нод и не убедились, что всё переживается штатно.
- Недооценка сети. Виртуальные серверы в разных дата-центрах или подсетях с высокой задержкой могут сделать
galera clusterнестабильным, а репликацию медленной.
Итоги
HA для WordPress — это не обязательно Kubernetes и десятки микросервисов. На обычных виртуальных серверах VDS можно собрать надёжную схему: несколько PHP-узлов за балансировщиком, объектный кеш и сессии в Redis, а в качестве базы — Galera или репликация MySQL в зависимости от приоритетов между простотой и консистентностью.
Главное — относиться к HA как к инженерному проекту: заранее продумать архитектуру, выбрать между galera cluster и mysql replicas, настроить единый endpoint для БД, синхронизацию файлов и кешей, а затем регулярно тестировать отказоустойчивость и восстановление из бэкапов. Тогда WordPress перестаёт быть «одним сервером под столом» и становится действительно доступным 24/7 сервисом.
