Tungsten + MySQL-Proxy: мульти-мастер на Ubuntu

Моя конфигурация

Для примера использовались три виртуальные машины:

Web Server 1: web1 — IP 192.168.56.101
Master 1: master1 — IP 192.168.56.10
Master 2: master2 — IP 192.168.56.11

Эта схема подразумевает один балансировщик на веб-хосте, два мастера MySQL, каждый из которых выступает и как мастер, и как реплика для другого (multi-master через промежуточный репликатор).

Установка веб‑сервера

На веб-сервере выполните вход под root и запустите tasksel, чтобы установить LAMP (Apache, PHP, MySQL-frontend).

Команды:

$ sudo su
$ tasksel

Выберите опцию “LAMP server” и подтвердите. Это упрощённый шаг — подробная настройка Apache и PHP не описана, так как фокус — на репликации и прокси.

Конфигурация MySQL-Proxy на веб‑сервере

Установите mysql-proxy, затем укажите файл конфигурации по умолчанию.

Установка:

$sudo apt-get -y install mysql-proxy

Измените файл /etc/default/mysql-proxy:

$vi /etc/default/mysql-proxy

Добавьте/отредактируйте:

ENABLED="true"
OPTIONS="--defaults-file=/root/mysql-proxy.cnf"

Файл /root/mysql-proxy.cnf должен содержать настройки прокси — обратите внимание на backend-адреса и lua-скрипт балансировки:

[mysql-proxy]
daemon = true
proxy-address = 127.0.0.1:3305
proxy-skip-profiling = true
keepalive = true
event-threads = 50
pid-file = /var/run/mysql-proxy.pid
log-file = /var/log/mysql-proxy.log
log-level = debug
proxy-backend-addresses = 192.168.56.10:3306,192.168.56.11:3306
proxy-lua-script=/usr/lib/mysql-proxy/lua/proxy/balance.lua

Мы не запускаем mysql-proxy до настройки backend-серверов, чтобы не получить ошибку подключения.

Настройка MySQL‑серверов

Для простоты я настроил один сервер, а затем клонировал образ и изменил /etc/hostname, /etc/hosts и сетевые настройки на втором сервере.

Установка MySQL:

sudo su
apt-get install -y mysql-server

Подготовка серверов к установке Tungsten Replicator

Ниже — краткий список настроек, которые потребовалось изменить. Официальные требования находятся в документации Tungsten, но здесь — практические правки для Ubuntu 10.04.3 LTS.

MySQL

Файл /etc/mysql/my.cnf — ключевые параметры:

$ cat /etc/mysql/my.cnf

[mysqld]
# Master replication settings.
server-id=1
# set increment for up to 4 servers
auto_increment_increment = 4
# increment offset for this server, next server would be 2
auto_increment_offset = 1
log-bin=mysql-bin
# Required InnoDB parameter settings for Tungsten.  Buffer pool size may be 
# larger but should not be smaller for production deployments. 
innodb_buffer_pool_size = 512M
# Recommended InnoDB settings for Tungsten.  
default-table-type=InnoDB
innodb_flush_log_at_trx_commit=2
sync_binlog=0
# Recommended general settings.  max_allowed_packet must be greater than
# the size of the largest transaction. 
max_allowed_packet=48m

Пояснения: server-id должен быть уникален для каждого сервера; autoincrement* полезны при записи с нескольких мастеров; innodb_flush_log_at_trx_commit=2 уменьшает нагрузку на диск, но снижает ACID — принимайте решение исходя из требований к данным.

Права пользователя MySQL

Tungsten использует учётную запись для воссоздания транзакций. Войдите как root и создайте пользователя:

$ mysql -u root -p

mysql> grant all on *.* to tungsten@'%' identified by 'secret' with grant option;

Используйте более сложный пароль в продакшене и ограничьте доступ по IP, если возможно.

Ruby

Tungsten требует Ruby и OpenSSL binding:

$ apt-get install -y ruby libopenssl-ruby

Тест:

  $ echo "p 'hello'" | ruby -ropenssl

Ожидаемый вывод:

"hello"

Java Virtual Machine

Tungsten требует JVM. На Ubuntu 10.04 можно использовать OpenJDK:

$ apt-get install openjdk-6-jre
$ echo $JAVA_HOME # Should point to Sun JDK install location
$ java -version

Как задать JAVA_HOME

Добавьте в конец /etc/bash.bashrc:

JAVA_HOME=/usr/lib/jvm/java-6-openjdk
export JAVA_HOME

Загрузите настройки:

$ source /etc/bash.bashrc

Сеть

Проверьте, что uname -n возвращает уникальное имя хоста, а hostname –ip-address разрешается в реальный (частный) IP.

Проверьте /etc/hosts:

... 
192.168.56.10   master1 
192.168.56.11   master2 
...

SSH

Настройте авторизацию по ключам для учётной записи, под которой будет запускаться Tungsten (у меня — root). Машина, с которой вы настраиваете Tungsten, должна уметь ssh без пароля подключаться к другим узлам.

$ sudo su
$ ssh-keygen
$ cat .ssh/id_rsa.pub

Скопируйте содержимое в файл .ssh/authorized_keys на другом узле и установите права:

$ chmod 0600 .ssh/authorized_keys

Установка Tungsten Replicator

Tungsten устанавливается на одной машине, с которой можно инициировать установку сервисов на других узлах.

Скачивание и распаковка бинарного билда:

$ wget http://tungsten-replicator.googlecode.com/files/tungsten-replicator-2.0.4.tar.gz
$ tar -zxvf tungsten-replicator-2.0.4.tar.gz
$ cd tungsten-replicator-2.0.4

Я использовал скрипт для конфигурации мастер-сервисов. Пример setup-masters.sh:

$ cat setup-masters.sh

#! /bin/bash
TUNGSTEN_HOME=/opt/replication
MASTER1=master1
MASTER2=master2
./tools/tungsten-installer \
    --master-slave \
    --master-host=$MASTER1 \
    --datasource-user=tungsten \
    --datasource-password=secret \
    --service-name=zoid \
    --home-directory=$TUNGSTEN_HOME \
    --cluster-hosts=$MASTER1 \
    --start-and-report
  ./tools/tungsten-installer \
    --master-slave \
    --master-host=$MASTER2 \
    --datasource-user=tungsten \
    --datasource-password=secret \
    --service-name=linus \
    --home-directory=$TUNGSTEN_HOME \
    --cluster-hosts=$MASTER2 \
    --start-and-report

После запуска скрипта каталог TUNGSTEN_HOME (/opt/replication/) будет заполнен. Далее нужно настроить службы-слейвы, чтобы события с одного мастера копировались и передавались на другой.

Пример layout (логическая схема):

master1: локальный мастер — zoid; удалённый слейв — linus (копирует события с master1 на master2)
master2: локальный мастер — linus; удалённый слейв — zoid (копирует события с master2 на master1)

Скрипт setup-slaves.sh в /opt/replication/tungsten:

$ cat setup-slaves.sh

#! /bin/bash
MASTER1=master1
MASTER2=master2
TUNGSTEN_TOOLS=tools
$TUNGSTEN_TOOLS/configure-service \
   --host $MASTER1 \
   -C -q \
   --local-service-name=zoid \
   --role=slave \
   --service-type=remote \
   --datasource=$MASTER1 \
   --master-thl-host=$MASTER2 \
   --svc-start linus
$TUNGSTEN_TOOLS/configure-service \
  --host $MASTER2 \
  -C -q \
  --local-service-name=linus \
  --role=slave \
  --service-type=remote \
  --datasource=$MASTER2 \
  --master-thl-host=$MASTER1 \
  --svc-start zoid

Запустите и проверьте, что сервисы активны:

root@master1:/opt/replication/tungsten# tungsten-replicator/bin/trepctl services

Примерный вывод (сокращён):

Processing services command...
NAME              VALUE
----              -----
appliedLastSeqno: 2296
appliedLatency  : 2.178
role            : slave
serviceName     : linus
serviceType     : remote
started         : true
state           : ONLINE
NAME              VALUE
----              -----
appliedLastSeqno: 1611
appliedLatency  : 0.953
role            : master
serviceName     : zoid
serviceType     : local
started         : true
state           : ONLINE
Finished services command...

Аналогичный вывод должен быть и на master2.

Запуск MySQL-Proxy

Запустите сервис mysql-proxy и проверьте прослушиваемые порты:

$ /etc/init.d/mysql-proxy start

Проверка:

$ netstat -tulnap | grep 3305

Если порт 127.0.0.1:3305 прослушивается, прокси работает. В конфигурации мы использовали адрес 127.0.0.1, чтобы ограничить доступ локально; для удалённого доступа укажите 0.0.0.0 или реальный IP — но будьте внимательны к безопасности.

Тестирование репликации

Установите phpMyAdmin на веб-сервере и добавьте три записи серверов в конфигурацию, чтобы видеть прокси и оба мастера.

Пример фрагмента конфигурации phpMyAdmin (как в исходнике):

$i++;
/* Authentication type */ 
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = '127.0.0.1';
$cfg['Servers'][$i]['port'] = '3305'; 
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
/* Select mysqli if your server has it */
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['AllowNoPassword'] = false;
$i++;
/* Authentication type */ 
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = '192.168.56.10';
$cfg['Servers'][$i]['port'] = '3306'; 
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
/* Select mysqli if your server has it */
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['AllowNoPassword'] = false;
$i++;
/* Authentication type */ 
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = '192.168.56.11';
$cfg['Servers'][$i]['port'] = '3306'; 
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
/* Select mysqli if your server has it */
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['AllowNoPassword'] = false;

В браузере откройте http://192.168.56.101/phpmyadmin/ и подключитесь к записям. Для теста: отключите один мастер (например, физически или отключив сеть), выполните запись на другом мастере и затем снова подключите первый — данные должны синхронизироваться через Tungsten.

Когда это может не сработать

Неправильные server-id или совпадающие бинарные логи приведут к конфликтам.
Сложные транзакции, изменяющие автоинкрементные поля или использующие пользовательские функции, могут некорректно реплицироваться.
Конфликты при одновременных записях в одни и те же строки: Tungsten транслирует события, но не обеспечивает автоматическое разрешение коллизий на уровне данных.
Старые версии Ubuntu, MySQL или Java могут привести к несовместимости (Ubuntu 10.04 — устаревшая; для продакшена рекомендую обновиться).

Альтернативы и когда их выбирать

Galera Cluster (Percona XtraDB Cluster) — синхронная многомастерная репликация, хорошо подходит для приложений, требующих сильной согласованности.
MySQL Group Replication — современная встроенная опция для множественных мастеров (MySQL 5.7+ / 8.0).
Использовать master-slave с интеллектуальным фейловером (Orchestrator) — проще и безопаснее для большинства приложений.

Выбор зависит от требований к согласованности, задержкам и наличию специалистов для поддержки.

Безопасность и жёсткая конфигурация

Используйте TLS/SSH туннель для защищённого соединения между прокси и бэкендами.
Ограничьте доступ пользователя tungsten по IP и минимизируйте права.
Регулярно делайте резервные копии binlog и снимки базы.
Обновите ОС и Java — Ubuntu 10.04 уже не поддерживается, обновление критично для продакшена.

Руководство по откату при инциденте

Если обнаружены нарушения репликации — остановите запись приложений на обоих мастерах (режим readonly).
Создайте snapshot/дамп текущих данных с обоих мастеров.
Определите точку согласования (GTID или позиция binlog). Вручную синхронизируйте данных от более полного мастера к другому, либо восстановите из бэкапа.
Перезапустите Tungsten и проверьте последовательность событий.
Возобновите записи поэтапно, следя за метриками задержки и ошибками.

Важно: проверяйте процедуру отката в контролируемой среде заранее.

Контрольный список развёртывания (чеклист)

Уникальные server-id в my.cnf
Настроенные auto_increment_increment/offset
Создан пользователь tungsten с ограниченными правами
Рабочая JVM и JAVA_HOME
Ruby и OpenSSL доступны
SSH-ключи настроены
/etc/hosts корректен на всех хостах
mysql-proxy настроен и тестирован локально
Tungsten службы работают и в состоянии ONLINE
Тестовые записи проходят и реплицируются

Критерии приёмки

Обе ноды принимают записи и данные приходят на вторую ноду в разумное время (ожидаемая задержка — определяется SLA).
При отключении одной из нод данные, записанные на другой, не теряются и применяются после возврата.
Метрики задержки и ошибок в логах Tungsten в норме.

Диаграмма принятия решений (Mermaid)

flowchart TD
  A[Начало: нужно ли мульти-мастер?] --> B{Требуется сильная согласованность?}
  B -- Да --> C[Использовать Galera или Group Replication]
  B -- Нет --> D{Нужно минимизировать риск конфликтов?}
  D -- Да --> C
  D -- Нет --> E[Рассмотреть Tungsten + Proxy или master-slave + Orchestrator]
  E --> F[Проводить нагрузочное тестирование]
  F --> G[Внедрять в тестовую среду]

Тесты и приёмочные сценарии

Создать запись на master1 и убедиться, что она появилась на master2.
Отключить сеть у master2, сделать запись на master1, затем включить master2 и проверить синхронизацию.
Выполнить конкурентные записи в один и тот же ряд с разных мастеров и проверить поведение (конфликтные сценарии).
Нагрузочный тест на запись и чтение через mysql-proxy и прямые соединения.

Короткие примечания и рекомендации

Важно: Ubuntu 10.04.3 LTS и указанные версии Tungsten/Java достаточно устарели. Для продакшен-среды планируйте миграцию на современные версии ОС и MySQL. Tungsten — мощное решение, но требует внимательной поддержки.

Примечание: в конфигурациях в примерах используется пароль ‘secret’ и общедоступные адреса. Меняйте пароли и ограничивайте доступ по сети.

Итог

Мульти-мастер с Tungsten и mysql-proxy даёт гибкую архитектуру для репликации между двумя MySQL-серверами и локальным балансировщиком на веб-хосте. Этот подход подходит для сценариев с ограниченной конкуренцией записей и где можно допустить гибкость в согласованности. Для задач с высокими требованиями к согласованности и современными стековыми требованиями рассмотрите Galera или Group Replication.

Ключевые действия: подготовить MySQL и окружение, установить Tungsten, настроить службы-master/slave друг на друга, запустить mysql-proxy и провести тесты.

Важно: протестируйте процедуру восстановления и отката до запуска в продакшен.

Как настроить мульти-мастер репликацию с Tungsten и MySQL-Proxy на Ubuntu 10.04.3 LTS