Хмарний сервер для MySQL в Європі
MySQL забезпечує роботу значної частки веб-застосунків у всьому світі - від блогів WordPress до платформ електронної комерції з великим трафіком. Для бізнесу, що обслуговує європейських користувачів, місце розташування хостингу вашої бази даних MySQL безпосередньо впливає як на статус відповідності GDPR, так і на час відповіді на запити.
Чому хостинг в ЄС важливий для MySQL
GDPR розглядає сервери баз даних як обробники даних. Якщо ваш екземпляр MySQL зберігає персональні дані - імена, електронні адреси, історії покупок - він повинен розміщуватися в юрисдикції, що забезпечує еквівалентний захист даних відповідно до законодавства ЄС.
Затримка мережі також є практичним питанням. Сервер MySQL у Центральній Європі додає 5-15 мс часу туди-назад до серверів застосунків у тому ж регіоні. Той же база даних у центрі обробки даних США додає 80-120 мс.
Мінімальні характеристики для MySQL
- Малий (dev/staging, менше 500 QPS) - 2 vCPU, 4 ГБ RAM, 50 ГБ NVMe SSD
- Середній (виробничий застосунок, 500-5000 QPS) - 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe SSD
- Великий (OLTP з великим трафіком або аналітика) - 16+ vCPU, 64-128 ГБ RAM, 1+ ТБ NVMe SSD
Пул буферів InnoDB повинен бути встановлений на 70-80% доступної RAM. На сервері з 32 ГБ це означає 22-25 ГБ для пулу буферів.
Рекомендована конфігурація DCXV
Хмарні сервери DCXV забезпечують сховище на базі NVMe з високим стабільним показником IOPS, що критично важливо для журналювання MySQL. Рекомендовані конфігурації:
- 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe - підходить для більшості виробничих веб-застосунків
- 16 vCPU, 64 ГБ RAM, 1 ТБ NVMe - платформи з великим трафіком або застосунки з читаючими репліками
Зв'яжіться з sales@dcxv.com для обговорення вашого співвідношення читання/запису.
Команди швидкого налаштування
# Встановлення MySQL 8.0 на Ubuntu 22.04
sudo apt update && sudo apt install -y mysql-server
# Запустіть майстер безпеки
sudo mysql_secure_installation
# Створення бази даних та користувача
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
innodb_buffer_pool_size = 24G
innodb_buffer_pool_instances = 8
innodb_redo_log_capacity = 1G
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
max_connections = 300
tmp_table_size = 256M
Що ламається першим і що з цим робити
Більшість гальмувань MySQL це не замалий сервер. Чотири з п'яти рядків нижче лікуються конфігурацією або запитом, і лише один справді вирішується залізом:
| Симптом | Звична причина | На що дивитися | Що робити |
|---|---|---|---|
| Читання гальмують, диск завантажений | Буферний пул менший за робочий набір | Hit rate буферного пулу InnoDB | Більше RAM, близько 70% з них у пул |
| Записи стають пачками | Redo log замалий, щоб їх поглинути | Checkpoint age, innodb_redo_log_capacity | Більший redo log |
| Усе добре, поки не запустять звіт | Один запит сканує таблицю | Slow query log, далі EXPLAIN | Індекс або репліка на читання під звіти |
| CPU в стелю, диск вільний | Дані влазять, платимо за запити | Threads_running | Спершу кращі запити, потім більший сервер |
| Відмови у підключенні | Підняли max_connections замість пулу | Threads_connected проти ліміту | Пул підключень, а не більше число |
Порядок важливий: заміряйте hit rate буферного пулу, перш ніж щось купувати. Пул, який уже вміщає робочий набір, не стане швидшим на більшому інстансі, і гроші краще витратити на запит, який сканує.
Очікувані показники продуктивності
На екземплярі з 8 vCPU / 32 ГБ RAM / NVMe з MySQL 8.0:
- sysbench OLTP лише читання (8 потоків) - 25 000-40 000 QPS
- sysbench OLTP читання-запис (8 потоків) - 8 000-14 000 TPS
- Затримка пошуку одного рядка (з індексом) - менше 1 мс
Це очікування для заліза цього класу, а не заміри в нашій лабораторії. Використовуйте їх як відправну точку для сайзингу і міряйте своє навантаження: реальні числа залежать від ваших даних, запитів і налаштувань значно більше, ніж від провайдера.
Висновок
MySQL на хмарному сервері ЄС задовольняє вимоги GDPR до резиденції даних, забезпечуючи при цьому продуктивність бази даних з малою затримкою та високою пропускною здатністю. Правильне налаштування InnoDB є найважливішим важелем продуктивності.
