Cloud Server for MySQL in Europe: InnoDB Tuning Guide
MySQL powers a huge share of web applications worldwide - from WordPress blogs to high-traffic e-commerce platforms. For businesses serving European users, the hosting location of your MySQL database directly affects both your GDPR compliance status and the query response times your users experience.
This guide covers the hardware MySQL needs to perform well, how to configure it on an EU cloud server, and what real-world throughput to expect.
Why EU Hosting Matters for MySQL Workloads
GDPR treats database servers as data processors. If your MySQL instance holds personal data - names, emails, purchase histories - it must be hosted within a jurisdiction that provides equivalent data protection to EU law. Hosting in the EU with an EU-based provider is the simplest way to satisfy this requirement without additional legal overhead.
Network latency is also a practical concern. A MySQL server in Central Europe adds 5-15ms round-trip time to application servers in the same region. The same database in a US data center adds 80-120ms. For applications making dozens of queries per page load, that difference is very visible to end users.
Minimum Specs for MySQL
MySQL’s performance is primarily bounded by RAM (for the InnoDB buffer pool) and I/O speed (for writes to the redo log and data files):
- Small (dev/staging, under 500 QPS) - 2 vCPU, 4 GB RAM, 50 GB NVMe SSD
- Medium (production app, 500-5000 QPS) - 8 vCPU, 32 GB RAM, 500 GB NVMe SSD
- Large (high-traffic OLTP or analytics) - 16+ vCPU, 64-128 GB RAM, 1+ TB NVMe SSD
The InnoDB buffer pool should be set to 70-80% of available RAM. On a 32 GB server, that means 22-25 GB for the buffer pool. When your working dataset fits in the buffer pool, MySQL serves reads entirely from memory.
Recommended DCXV Configuration
DCXV cloud servers provide NVMe-backed storage with high sustained IOPS, which is critical for MySQL’s write-ahead logging. Recommended configurations:
- 8 vCPU, 32 GB RAM, 500 GB NVMe - suitable for most production web applications
- 16 vCPU, 64 GB RAM, 1 TB NVMe - high-traffic platforms or applications with read replicas
All DCXV servers run on Tier III certified EU data centers. Private networking allows your application servers and database to communicate without traffic leaving the data center network, reducing latency and exposure.
Contact sales@dcxv.com to discuss your read/write ratio and get a configuration recommendation.
Quick Setup Commands
# Install MySQL 8.0 on Ubuntu 22.04
sudo apt update && sudo apt install -y mysql-server
# Run the security setup wizard
sudo mysql_secure_installation
# Start and enable the service
sudo systemctl start mysql
sudo systemctl enable mysql
# Create a database and user
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;"# Key my.cnf tuning for a 32 GB RAM server
# Edit /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
# InnoDB buffer pool - set to 70-80% of RAM
innodb_buffer_pool_size = 24G
innodb_buffer_pool_instances = 8 # one per 1-2 GB of buffer pool
# Write performance
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 1 # 1 = full ACID, 2 = faster but riskier
innodb_flush_method = O_DIRECT # avoid double buffering with OS cache
# Connections and temp tables
max_connections = 300
tmp_table_size = 256M
max_heap_table_size = 256M
# Query cache (disabled in MySQL 8.0 by default - use ProxySQL or app-level caching)
# Restart after changes# Restart MySQL after config changes
sudo systemctl restart mysql
# Verify buffer pool size is applied
sudo mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
# Check InnoDB status for hit rate (aim for >99%)
sudo mysql -e "SHOW STATUS LIKE 'Innodb_buffer_pool_reads';"
sudo mysql -e "SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests';"# Set up a read replica on a second DCXV server
# On the primary - enable binary logging
# Add to mysqld.cnf:
# server-id = 1
# log_bin = /var/log/mysql/mysql-bin.log
# binlog_do_db = myapp
# Create replication user on primary
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.%';"
# On the replica server, configure and start replication
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 STATUSG"Expected Performance Benchmarks
On a DCXV 8 vCPU / 32 GB RAM / NVMe instance with MySQL 8.0 and proper InnoDB tuning:
- sysbench OLTP read-only (8 threads) - 25,000-40,000 QPS
- sysbench OLTP read-write (8 threads) - 8,000-14,000 TPS
- Single-row lookup latency (indexed) - under 1ms
- Bulk INSERT (1M rows, batch 1000) - under 90 seconds
Buffer pool hit rate above 99% is achievable when the working set fits in RAM. At that point, most reads never touch disk, and performance is CPU-bound.
Bottom Line
MySQL on an EU cloud server satisfies GDPR data residency requirements while delivering the low-latency, high-throughput database performance that production applications need. Proper InnoDB tuning is the single biggest performance lever - set your buffer pool to 70-80% of RAM and configure O_DIRECT flushing. DCXV cloud servers provide the NVMe I/O and EU data residency your workload requires.
