Вопрос или проблема
Я настроил архитектуру репликации master/slave для MariaDB в Docker для своего сайта на WordPress, но заметил, что производительность не улучшилась, и я разочарован! Но я хотел бы знать, что не так или что я упустил? Вот файл docker-compose:
services:
sv-isoluce-db-master-1:
build:
context: ./buildimg/mariadb
dockerfile: Dockerfile
image: img-isoluce-mariadb
container_name: ct-isoluce-mariadb-master-1
environment:
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
volumes:
- vl-isoluce-ct-mariadb-master-1:/var/lib/mysql
- ./ctconfig/mariadb-master-1.cnf:/etc/mysql/my.cnf
- ./ctconfig/01-init-db-master.sql:/docker-entrypoint-initdb.d/01-init-db-master.sql
ports:
- "3301:3306"
networks:
- nw_isoluce_mariadb_cluster_network
sv-isoluce-db-slave-2:
image: img-isoluce-mariadb
container_name: ct-isoluce-mariadb-slave-2
depends_on:
- sv-isoluce-db-master-1
environment:
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MASTER_HOST=${MASTER_HOST}
- MASTER_PORT=${MASTER_PORT}
- REPLICATION_USER=${REPLICATION_USER}
- REPLICATION_PASSWORD=${REPLICATION_PASSWORD}
volumes:
- vl-isoluce-ct-mariadb-slave-2:/var/lib/mysql
- ./ctconfig/mariadb-slave-2.cnf:/etc/mysql/my.cnf
ports:
- "3302:3306"
networks:
- nw_isoluce_mariadb_cluster_network
sv-isoluce-db-slave-3:
image: img-isoluce-mariadb
container_name: ct-isoluce-mariadb-slave-3
depends_on:
- sv-isoluce-db-master-1
environment:
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MASTER_HOST=${MASTER_HOST}
- MASTER_PORT=${MASTER_PORT}
- REPLICATION_USER=${REPLICATION_USER}
- REPLICATION_PASSWORD=${REPLICATION_PASSWORD}
volumes:
- vl-isoluce-ct-mariadb-slave-3:/var/lib/mysql
- ./ctconfig/mariadb-slave-3.cnf:/etc/mysql/my.cnf
ports:
- "3303:3306"
networks:
- nw_isoluce_mariadb_cluster_network
sv-isoluce-haproxy:
build:
context: ./buildimg/haproxy
dockerfile: Dockerfile
image: img-isoluce-haproxy
container_name: ct-isoluce-haproxy
depends_on:
- sv-isoluce-db-master-1
- sv-isoluce-db-slave-2
- sv-isoluce-db-slave-3
volumes:
- ./buildimg/haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
ports:
- "3307:3307"
- "8888:8888"
networks:
- nw_isoluce_mariadb_cluster_network
sv-isoluce-phpmyadmin:
image: phpmyadmin/phpmyadmin:latest
container_name: ct-isoluce-phpmyadmin
depends_on:
- sv-isoluce-db-master-1
- sv-isoluce-db-slave-2
- sv-isoluce-db-slave-3
environment:
PMA_ARBITRARY: 1
PMA_HOST: sv-isoluce-db-master-1
PMA_PORT: 3306
ports:
- "3300:80"
networks:
- nw_isoluce_mariadb_cluster_network
volumes:
vl-isoluce-ct-mariadb-master-1:
name: vl-isoluce-ct-mariadb-master-1
vl-isoluce-ct-mariadb-slave-2:
name: vl-isoluce-ct-mariadb-slave-2
vl-isoluce-ct-mariadb-slave-3:
name: vl-isoluce-ct-mariadb-slave-3
networks:
nw_isoluce_mariadb_cluster_network:
name: nw_isoluce_mariadb_cluster_network
driver: bridge
Вот Dockerfile, который я использовал для создания образа mariadb (ничего особенного):
# Официальный образ MariaDB как база
FROM mariadb:latest
# Устанавливаем утилиты: iputils-ping...
RUN apt-get update && apt-get install -y \
iputils-ping \
vim \
nano \
net-tools \
htop \
wget \
curl \
atop \
netcat-openbsd \
systemd \
procps \
locate \
telnet \
libhiredis-dev \
libmariadb3 \
libmariadb-dev
# Открываем стандартный порт MariaDB
EXPOSE 3306
Вот конфигурационный файл mariadb для главного узла:
[mysqld]
bind-address = 0.0.0.0
gtid_domain_id = 1
server-id = 01
log-bin = /var/log/mysql/master-bin
log-bin-index = /var/log/mysql/master-bin.index
binlog-format = mixed
log_slave_updates = 1
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
log_error = /var/log/mysql/error.log
general_log = on
general_log_file = /var/log/mysql/mysql.log
replicate-do-db = wp_bsarp
log-slave-updates = 1
expire_logs_days = 10
gtid_strict_mode = ON
performance_schema = ON
performance_schema_instrument="%=ON"
performance_schema_consumer_events_statements_current = ON
performance_schema_consumer_events_statements_history = ON
И конфигурационный файл для узлов-слейвов:
[mysqld]
bind-address = 0.0.0.0
gtid_domain_id = 1
server-id = 02
log-bin = /var/log/mysql/02-bin
log-bin-index = /var/log/mysql/02-bin.index
binlog_format = mixed
relay-log-index = /var/log/mysql/slave-relay-bin.index
relay-log = /var/log/mysql/slave-relay-bin
log_slave_updates = ON
replicate-do-db = wp_bsarp
slave-skip-errors = 1062
skip-slave-start
log_error = /var/log/mysql/error.log
general_log = on
general_log_file = /var/log/mysql/mysql.log
gtid_strict_mode = ON
performance_schema = ON
performance_schema_instrument="%=ON"
performance_schema_consumer_events_statements_current = ON
performance_schema_consumer_events_statements_history = ON
Что касается HAProxy:
global
log stdout format raw local0 debug
log 127.0.0.1 local0
stats socket /var/run/api.sock user haproxy group haproxy mode 660 level admin expose-fd listeners
defaults
mode http
timeout client 30s
timeout connect 30s
timeout server 30s
timeout http-request 30s
log global
frontend mysql_frontend
bind *:3307
mode tcp
option tcplog
log-format "%ci:%cp [%t] %s %hr %b %tr %ts %ac %fc %bc %rc %sc %sq %bq %hr %hs"
tcp-request inspect-delay 5s
tcp-request content accept if { req_len 10 }
acl is_read_query req.body -m sub "SELECT"
use_backend mysql_read_backend if is_read_query
default_backend mysql_write_backend
backend mysql_write_backend
mode tcp
balance roundrobin
option tcp-check
tcp-check connect
server hap-mariadb-master-1_write_backend sv-isoluce-db-master-1:3306 check
backend mysql_read_backend
mode tcp
balance roundrobin
option tcp-check
tcp-check connect
server hap-mariadb-master-1_read_backend sv-isoluce-db-master-1:3306 check
server hap-mariadb-slave-2_read_backend sv-isoluce-db-slave-2:3306 check
server hap-mariadb-slave-3_read_backend sv-isoluce-db-slave-3:3306 check
Это работает, но очень медленно… есть идеи? Спасибо.
Я ожидаю улучшения производительности, но на самом деле, это ничего не меняет, будь то с единственным сервером базы данных или с распределенной архитектурой master/slave…
Ответ или решение
Судя по вашему описанию проблемы с медленной работой архитектуры master/slave для базы данных MariaDB в Docker, давайте рассмотрим возможные причины низкой производительности и решения, которые помогут вам оптимизировать систему.
1. Виды нагрузки и оптимизация чтения/записи
Ваша конфигурация, похоже, подразумевает использование репликации, однако важно понять, как ваш WordPress использует базу данных. Если приложение в основном выполняет операции записи (например, создание, обновление контента), то добавление слейвов не принесет значительного улучшения производительности, так как запись происходит только на мастере. Репликация в большинстве случаев полезна для уменьшения нагрузки на чтение, так что стоит рассмотреть возможность оптимизации запросов на чтение.
Решение: Убедитесь, что вы распределяете операции между мастером и слейвами. Например, все запросы на чтение должны идти к слейвам, а операции записи — на мастера. Используйте HAProxy для маршрутизации запросов в зависимости от типа операции.
2. Настройки HAProxy
Проблемы могут возникать из-за неправильной настройки HAProxy, которая неэффективно обрабатывает запросы. Например, в вашем конфигурационном файле HAProxy нет обработки ошибок или контроля за успешным состоянием слейвов.
Решение:
- Убедитесь, что маршрутизация запросов действительно работает. Проверьте конфигурацию HAProxy и убедитесь, что read-запросы действительно направляются к слейвам, а write-запросы к мастеру.
- Добавьте проверки состояния для слейвов, чтобы HAProxy исключал их из балансировки, если они недоступны или отстают по времени.
3. Конфигурация MariaDB
Ваши конфиг-файлы для MariaDB выглядят в целом правильными, однако есть нюансы, которые могут ухудшать производительность.
Решение:
- Убедитесь, что настройки
innodb_buffer_pool_size
и других параметров производительности хорошо подходят для вашего объема данных.innodb_buffer_pool_size
должна быть достаточной для хранения значительной части ваших часто используемых данных. - Рассмотрите возможность изменения параметров записи, таких как
innodb_flush_log_at_trx_commit
иsync_binlog
. Например, установкаinnodb_flush_log_at_trx_commit
в 2 может дать прирост производительности, но вы должны быть готовы к потерям в случае сбоя в течение секунды.
4. Сетевые задержки
Поскольку вы используете Docker, возможно, сеть между контейнерами создает некоторые задержки.
Решение:
- Попробуйте использовать "host" сеть вместо стандартной bridged. Это может улучшить производительность, так как контейнеры будут иметь более быстрый доступ к сети.
- Проверьте использование ресурсов на хосте, чтобы убедиться, что нет проблем с CPU или памятью, которые могут задерживать контейнеры.
5. Мониторинг и диагностика
Запустите мониторинг базы данных, чтобы увидеть, какие запросы выполняются долго, и идентифицировать узкие места.
Решение:
- Используйте такие инструменты, как
pt-query-digest
или встроенные средства мониторинга MariaDB, для анализа медленных запросов. - Смотрите на
SHOW PROCESSLIST
, чтобы видеть, в каком состоянии находятся ваши соединения и запросы.
Заключение
Настройка архитектуры master/slave требует комплексного подхода и оптимизации на разных уровнях — от конфигурации базы данных до характеристик сети и архитектуры приложения. Примените вышеперечисленные решения, и это должно помочь вам значительно улучшить производительность вашей системы MariaDB, настроенной в Docker. Если проблемы сохраняются, возможно, стоит рассмотреть возможность консультации со специалистом по производительности баз данных.