Облачный сервер для MySQL в Европе: руководство по настройке InnoDB
MySQL держит на себе огромную долю веб-приложений по всему миру - от блогов на WordPress до платформ электронной торговли с высоким трафиком. Для компаний, обслуживающих европейских пользователей, место размещения базы MySQL напрямую влияет и на соответствие GDPR, и на время отклика запросов, которое ощущают пользователи.
Это руководство описывает, какое оборудование нужно MySQL для хорошей работы, как настроить его на облачном сервере в ЕС и какой пропускной способности ждать на практике.
Почему хостинг в ЕС важен для нагрузок MySQL
GDPR рассматривает серверы баз данных как обработчиков данных. Если ваш экземпляр MySQL хранит персональные данные - имена, адреса почты, историю покупок, - он должен размещаться в юрисдикции, обеспечивающей защиту данных, равноценную праву ЕС. Хостинг в ЕС у провайдера из ЕС - самый простой способ выполнить это требование без дополнительной юридической нагрузки.
Сетевая задержка тоже практический вопрос. Сервер MySQL в Центральной Европе добавляет 5-15 мс времени оборота до серверов приложений в том же регионе. Та же база в дата-центре США добавляет 80-120 мс. Для приложений, делающих десятки запросов на загрузку страницы, эта разница очень заметна конечному пользователю.
Минимальные требования к серверу для MySQL
Производительность MySQL в первую очередь ограничена объёмом RAM (для буферного пула InnoDB) и скоростью ввода-вывода (для записи в журнал повторного выполнения и файлы данных):
- Небольшой (разработка и стейджинг, менее 500 запросов в секунду) - 2 vCPU, 4 ГБ RAM, 50 ГБ NVMe SSD
- Средний (продакшен-приложение, 500-5000 запросов в секунду) - 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe SSD
- Крупный (OLTP с высоким трафиком или аналитика) - 16 и более vCPU, 64-128 ГБ RAM, 1 ТБ и более NVMe SSD
Буферный пул InnoDB следует задать в 70-80% доступной RAM. На сервере с 32 ГБ это 22-25 ГБ на пул. Когда рабочий набор данных помещается в буферный пул, MySQL отдаёт чтения целиком из памяти.
Рекомендуемая конфигурация DCXV
Облачные серверы DCXV дают хранилище на NVMe с высоким устойчивым IOPS, что критично для журналирования записей MySQL. Рекомендуемые конфигурации:
- 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe - подходит большинству продакшен-приложений
- 16 vCPU, 64 ГБ RAM, 1 ТБ NVMe - платформы с высоким трафиком или приложения с репликами для чтения
Все серверы DCXV работают в сертифицированных по Tier III дата-центрах ЕС. Приватная сеть позволяет серверам приложений и базе обмениваться данными без выхода трафика из сети дата-центра, что снижает задержку и уменьшает открытую поверхность.
Напишите на sales@dcxv.com, чтобы обсудить соотношение чтения и записи в вашей нагрузке и получить рекомендацию по конфигурации.
Команды для быстрой установки
# Установка MySQL 8.0 на Ubuntu 22.04
sudo apt update && sudo apt install -y mysql-server
# Запуск мастера настройки безопасности
sudo mysql_secure_installation
# Запуск и включение службы
sudo systemctl start mysql
sudo systemctl enable mysql
# Создание базы и пользователя
sudo mysql -e "CREATE DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
sudo mysql -e "CREATE USER 'myapp_user'@'10.0.0.%' IDENTIFIED BY 'strongpassword';"
sudo mysql -e "GRANT ALL PRIVILEGES ON myapp.* TO 'myapp_user'@'10.0.0.%';"
sudo mysql -e "FLUSH PRIVILEGES;"
# Ключевые параметры my.cnf для сервера с 32 ГБ RAM
# Правьте /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
# Буферный пул InnoDB - задайте 70-80% RAM
innodb_buffer_pool_size = 24G
innodb_buffer_pool_instances = 8 # один на 1-2 ГБ пула
# Производительность записи
innodb_redo_log_capacity = 1G
innodb_flush_log_at_trx_commit = 1 # 1 = полный ACID, 2 = быстрее, но рискованнее
innodb_flush_method = O_DIRECT # без двойной буферизации с кешем ОС
# Соединения и временные таблицы
max_connections = 300
tmp_table_size = 256M
max_heap_table_size = 256M
# Кеш запросов (в MySQL 8.0 отключён по умолчанию - используйте ProxySQL или кеш на уровне приложения)
# После изменений перезапустите
# Перезапуск MySQL после правки конфигурации
sudo systemctl restart mysql
# Проверка, что размер буферного пула применён
sudo mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
# Проверка состояния InnoDB для доли попаданий (цель выше 99%)
sudo mysql -e "SHOW STATUS LIKE 'Innodb_buffer_pool_reads';"
sudo mysql -e "SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests';"
# Настройка реплики для чтения на втором сервере DCXV
# На основном - включите двоичный журнал
# Добавьте в mysqld.cnf:
# server-id = 1
# log_bin = /var/log/mysql/mysql-bin.log
# binlog_do_db = myapp
# Создание пользователя репликации на основном
sudo mysql -e "CREATE USER 'replica'@'10.0.0.%' IDENTIFIED WITH mysql_native_password BY 'replicapass';"
sudo mysql -e "GRANT REPLICATION SLAVE ON *.* TO 'replica'@'10.0.0.%';"
# На сервере реплики настройте и запустите репликацию
sudo mysql -e "CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.0.5', SOURCE_USER='replica', SOURCE_PASSWORD='replicapass', SOURCE_AUTO_POSITION=1;"
sudo mysql -e "START REPLICA;"
sudo mysql -e "SHOW REPLICA STATUS\G"
Что сдаёт первым и что с этим делать
Большинство замедлений MySQL - это не слишком маленький сервер. Четыре из пяти строк ниже решаются настройкой или запросом, и только одна отвечает добавлением оборудования:
| Симптом | Обычная причина | На что смотреть | Решение |
|---|---|---|---|
| Чтения медленные, диск занят | Буферный пул меньше рабочего набора | Доля попаданий в буферный пул InnoDB | Больше RAM, около 70% из неё в пул |
| Записи встают всплесками | Журнал повторного выполнения мал, чтобы их принять | Возраст контрольной точки, innodb_redo_log_capacity | Более крупный журнал |
| Всё хорошо, пока не запустится отчёт | Один запрос сканирует таблицу | Журнал медленных запросов, затем EXPLAIN | Индекс или реплика для чтения под отчёты |
| CPU загружен, диск простаивает | Данные помещаются, а стоят сами запросы | Threads_running | Лучше запросы, чем более крупный сервер |
| Соединения отклоняются | max_connections поднят вместо пула | Threads_connected против предела | Пул соединений, а не большее число |
Порядок важен: измерьте долю попаданий в буферный пул до любой покупки. Пул, который уже вмещает рабочий набор, не станет быстрее на более крупном инстансе, и деньги лучше потратить на запрос, который сканирует.
Ожидаемые показатели производительности
На инстансе 8 vCPU / 32 ГБ RAM / NVMe с MySQL 8.0 и правильной настройкой InnoDB:
- sysbench OLTP только чтение (8 потоков) - 25 000-40 000 запросов в секунду
- sysbench OLTP чтение и запись (8 потоков) - 8 000-14 000 транзакций в секунду
- Задержка выборки одной строки (по индексу) - менее 1 мс
- Пакетный INSERT (1 млн строк, партии по 1000) - менее 90 секунд
Доля попаданий в буферный пул выше 99% достижима, когда рабочий набор помещается в RAM. В этой точке большинство чтений не касается диска, и производительность ограничена CPU.
Это ожидания для оборудования такого класса, а не измерения из нашей лаборатории. Считайте их отправной точкой для расчёта и измеряйте собственную нагрузку: реальные цифры зависят от ваших данных, ваших запросов и вашей настройки гораздо сильнее, чем от провайдера.
Итог
MySQL на облачном сервере в ЕО выполняет требования GDPR к месту хранения данных и при этом даёт низкую задержку и высокую пропускную способность, которые нужны продакшен-приложениям. Правильная настройка InnoDB - самый мощный рычаг производительности: задайте буферный пул в 70-80% RAM и включите сброс через O_DIRECT. Облачные серверы DCXV дают ввод-вывод NVMe и хранение данных в ЕС, которые нужны вашей нагрузке.
