Быстрые и предсказуемые базы данных на bare metal с NVMe Gen5

На современном оборудовании производительность базы данных в основном определяется тем, что помещается в память. Оцените рабочий набор — таблицы и индексы, к которым ваши запросы обращаются за типичный час, — а не полный объём на диске. Если он с запасом помещается в RAM, чтение идёт из памяти, а NVMe-накопители принимают в основном запись.

Отправные точки для сервера, выделенного под базу данных:

• PostgreSQL: shared_buffers — около 25% RAM, effective_cache_size — около 75%; остальное берёт на себя страничный кэш ОС.
• MySQL и MariaDB (InnoDB): innodb_buffer_pool_size — 60–75% RAM.
• Redis и Valkey: задайте maxmemory заметно ниже физического объёма RAM, оставив запас для снапшотов через fork.

Для оценки: если около 30% RAM остаётся свободным под соединения, сортировки и ОС, Pro 32 кэширует рабочий набор примерно в 270 ГБ, Pro 48 — около 400 ГБ, а Pro 64 — около 540 ГБ. Важна и пропускная способность: 12 каналов DDR5-6000 дают каждому сокету EPYC 9005 около 576 ГБ/с теоретической пиковой пропускной способности памяти.

В каждом сервере Pro не меньше двух накопителей NVMe Gen5 — объедините их в зеркало. Программный RAID 1 на mdadm или зеркало ZFS сохраняет работу базы при отказе диска, а запасные комплектующие на площадке в каждой локации позволяют быстро заменить вышедший из строя накопитель. На Pro 64 массив RAID 10 из четырёх дисков даёт примерно вдвое большую пропускную способность на запись, чем одно зеркало.

Что важнее чистой скорости дисков:

• Файловая система: XFS или ext4 с опцией монтирования noatime. Для ZFS обычная отправная точка — recordsize, равный размеру страницы базы данных: 8K для PostgreSQL, 16K для InnoDB.
• Никакого RAID с чётностью для баз с интенсивной записью: RAID 5 и 6 превращают мелкие случайные записи в циклы read-modify-write.
• Сначала бенчмарки: перед миграцией запустите fio с вашим размером блока и pgbench или sysbench с вашим уровнем конкурентности, а результаты сохраните как точку отсчёта.
• Свободное место: файловые системы с copy-on-write и SSD замедляются при почти полном заполнении, поэтому планируйте заполнение не выше примерно 80%.

Пошаговая настройка описана в нашем руководстве по программному RAID на NVMe с mdadm.

Разместите резервный сервер в той же локации и подключите его через бесплатную частную VLAN: репликация не выходит на публичный интерфейс, а внутренний трафик не тарифицируется. Типовая схема высокой доступности:

• Два одинаковых сервера Pro — основной (primary) и резервный (standby) — с синхронной или асинхронной репликацией.
• Менеджер переключения (failover): Patroni с etcd для PostgreSQL или MySQL InnoDB Cluster, плюс третий небольшой узел для кворума, например Core 16.
• Слой маршрутизации: HAProxy с проверками состояния Patroni или MySQL Router, чтобы клиенты всегда попадали на текущий primary. Для пула соединений добавьте PgBouncer.

Для аварийного восстановления добавьте асинхронную реплику во второй локации — через WireGuard или TLS. Трафик безлимитный, поэтому репликация между площадками не добавляет расходов на трафик. Храните резервные копии отдельно от реплик: реплика мгновенно повторит ошибочный DELETE, а резервная копия позволит вернуться в прошлое. Для больших архивов хорошо подходят pgBackRest или Percona XtraBackup с сохранением копий на Storage 264.