Песочница →
Репликация MySql -> Oracle средствами Tungsten Replicator
Репликация MySql
Итак, начнем.
Установка:
На MySql понадобиться проставить бинлоги в формате RAW. Это необходимо исключительно для скриптов фильтрации и было частью бизнес-логики. Если фильтровать Вам не обязательно, или пишите свой скрипт — вполне можно и не менять формат бинлогов.
Качаем сам tungsten replicator (http://code.google.com/p/tungsten-replicator/), и устанавливаем на мастере (MySql сервер) и на слейве (Oracle). Он потребует ruby и java. Все ставил из дистрибутивов без каких-либо проблем.
Работать Tungsten у нас будет по следующей схеме:
Скрипт инсталляции для мастера:
./tools/tungsten-installer --master-slave -a --cluster-hosts=127.0.0.1 \
--master-host=127.0.0.1 \
--user=root \
--home-directory=/opt/repl \
--datasource-port=3306 \
--datasource-user= \
--datasource-password= \
--service-name=oracle \
--rmi-port=10000 \
--thl-port=2112 \
--mysql-enable-enumtostring=true \
--mysql-use-bytes-for-string=false \
--skip-validation-check=MySQLNoMySQLReplicationCheck
В целом — все думаю понятно, «service-name» — как будет сервис обозван, и в мускуле возникнет схема — tungsten_<service-name>. Она нам еще пригодится.
Юзер под которым крутится только в примере root, потом или сразу переставьте, под кем Вам удобнее. В примерах будет использоваться root.
На слейве:
./tools/tungsten-installer --master-slave -a --cluster-hosts=localhost \
--user=root \
--master-host=<IP мастера> \
--home-directory=/opt/repl \
--datasource-type=oracle \
--datasource-oracle-service= \
--datasource-user= \
--datasource-password= \
--service-name=frommysql \
--rmi-port=10000 \
--master-thl-port=2112
Пока что, все просто. После выполнения этих не хитрых операций — мы будем работать только с копией в папке куда проинсталлировали (/opt/repl/...).
Не торопимся запускать репликатор, так сходу все равно не запустится корректно — будет ругаться в логах на нехватку конфигов, т.к. имена конфигов будет желать в зависимости от имени схемы. Переименовываем replicator.properties в static-<имя схемы>.properties, в моем случае — static-oracle.properties.
В конфиге (/opt/repl/tungsten/tungsten-replicator/conf/...) на мастере указываем какие фильтры будут использоваться:
replicator.stage.binlog-to-q.filters=dropcomments,filtertables,dbupper
и сам путь до фильтра, и соответственно таблицы которые будут реплицироваться:
replicator.filter.filtertables=com.continuent.tungsten.replicator.filter.JavaScriptFilter
replicator.filter.filtertables.script=/opt/repl/tungsten/tungsten-replicator/filtertables.js
replicator.filter.filtertables.include=idp.abyrvalg,idp.transactions
В данном случае — схема idp и таблицы abyrvalg и transactions.
Убеждаемся, что мастер слушает порт, по которому к нему будет обращаться слейв для забирания thl логов
replicator.master.listen.uri=thl://0.0.0.0:2112/
В replicator.source_id= указываем любое уникальное имя. Проще всего — IP сервера. В моем случае — 192.168.40.3
В конце повествования будут приложены боевые конфиги и разумеется скрипт фильтрации.
Стартуем репликатор на мастере ./replicator start
Проверим его переход в онлайн — ./trepctl status, если офлайн — ./trepctl online
Если статус онлайн — значит все хорошо, он начал складировать у себя бинлоги MySql (по умолчанию, когда они превышают гигабайт — он их сам трет) и thl файлы — собственно что он будет слать слейву, об этом речь еще зайдет чуть ниже. Тут проблем быть не должно.
На слейве соответственно конфиг файл переименовываем в static-<имя схемы>.properties, в моем случае — static-frommysql.properties.
Убеждаемся, что в значении replicator.master.connect.uri=thl://<IP мастера>:2112 точно установлен IP мастера, явки и пароли верны.
replicator.source_id= — опять же любое уникальное значение,
закомментируем replicator.store.thl.storageListenerUri.
Создаем в указанной в конфиге слейва оракла таблицу, соответствующую реплицируемой.
Запускаем слейв — ./replicator start
Если он перешел с состояние по статусу online — все хорошо. Если нет — будет ругаться в логах и статусах.
Можно зайти в созданные схемы на местере и слейве, и обратить внимание — в таблице trep_commit_seqno меняются значения seqno и epoch_number.
Если все ок — можно уменьшить уровень логирования подредактировав wrapper.conf
Немного ухода за пациентом.
На мастере thl логи хранятся сколько указано в конфиге, по умолчанию — день. (replicator.store.thl.log_file_retention=), меняем на нужное нам, на слейве тоже самое. Но если нам срочно потребовалось высвободить место, то придется делать это вручную. Главное — не затереть последний эвент.
На мастере по умолчанию хранятся bin логи в размере не более 1 гигабайта (/opt/repl/relay/...), но для чистки thl вручную на слейве и мастере надо смотреть верхнее и нижнее значение уже записанных эвентов.
Собственно — сей кривой скрипт на мастере и слейве и занимается у меня этим.
#!/bin/sh
cd /opt/repl/tungsten/tungsten-replicator/bin
MINVALUE=`./thl -service frommysql info | grep «min seq# = » | awk '{print $4;}'`
MAXVALUE=`./trepctl status | grep «appliedLastSeqno: » | awk '{print $3;}'`
MAXVALUENEW=`echo "$MAXVALUE-1000" | bc`
./trepctl -service frommysql offline
sleep 10
./thl purge -low $MINVALUE -high $MAXVAskyrimLUENEW -y
./trepctl -service frommysql online
Немного траблшутинга.
Если мы случайно стерли лишнее, либо сеть между серверами лежала длительное время, или случился еще ряд причин, но при коннекте слейв пишет что увы и ах — но он хочет позицию N, а у мастера ее нету, что-нибудь вроде:
INFO | jvm 1 | 2011/11/24 11:32:54 | 2011-11-24 11:32:54,432 [oracle — connector-handler-192.168.39.50] ERROR thl.ConnectorHandler Connector handler terminated by THL exception: Log seek failure: expected seqno=XXXXXXX found seqno=YYYYYYY
(более точно смотрим либо в статусе, либо в логах) — то придется немного подчистить.
Останавливаем репликацию на слейве. Вытираем скопированные thl логи. Обращаем внимание на таблицу trep_commit_seqno. Затираем значения seqno и epoch_number, либо ставим ожидаемые мастером значения, смотря чего он хочет. Запускаем. Дальше придется, конечно, утерянный фрагмент по старинке перегонять из MySql в Oracle (через csv).
Так же, возможно сделать считывание с определенной позиции, см. документацию на официальном сайте, пункты 4.3.x
Конфиг мастера, конфиг слейва и js-скрипт фильтрации:
_http://zalil.ru/32217860
В целом — Tungsten replicator показал себя как очень гибкий и мощный, но не очень хорошо документированный продукт, позволяющий производить репликацию между различными БД под различные задачи.
Итак, начнем.
Установка:
На MySql понадобиться проставить бинлоги в формате RAW. Это необходимо исключительно для скриптов фильтрации и было частью бизнес-логики. Если фильтровать Вам не обязательно, или пишите свой скрипт — вполне можно и не менять формат бинлогов.
Качаем сам tungsten replicator (http://code.google.com/p/tungsten-replicator/), и устанавливаем на мастере (MySql сервер) и на слейве (Oracle). Он потребует ruby и java. Все ставил из дистрибутивов без каких-либо проблем.
Работать Tungsten у нас будет по следующей схеме:
Скрипт инсталляции для мастера:
./tools/tungsten-installer --master-slave -a --cluster-hosts=127.0.0.1 \
--master-host=127.0.0.1 \
--user=root \
--home-directory=/opt/repl \
--datasource-port=3306 \
--datasource-user= \
--datasource-password= \
--service-name=oracle \
--rmi-port=10000 \
--thl-port=2112 \
--mysql-enable-enumtostring=true \
--mysql-use-bytes-for-string=false \
--skip-validation-check=MySQLNoMySQLReplicationCheck
В целом — все думаю понятно, «service-name» — как будет сервис обозван, и в мускуле возникнет схема — tungsten_<service-name>. Она нам еще пригодится.
Юзер под которым крутится только в примере root, потом или сразу переставьте, под кем Вам удобнее. В примерах будет использоваться root.
На слейве:
./tools/tungsten-installer --master-slave -a --cluster-hosts=localhost \
--user=root \
--master-host=<IP мастера> \
--home-directory=/opt/repl \
--datasource-type=oracle \
--datasource-oracle-service= \
--datasource-user= \
--datasource-password= \
--service-name=frommysql \
--rmi-port=10000 \
--master-thl-port=2112
Пока что, все просто. После выполнения этих не хитрых операций — мы будем работать только с копией в папке куда проинсталлировали (/opt/repl/...).
Не торопимся запускать репликатор, так сходу все равно не запустится корректно — будет ругаться в логах на нехватку конфигов, т.к. имена конфигов будет желать в зависимости от имени схемы. Переименовываем replicator.properties в static-<имя схемы>.properties, в моем случае — static-oracle.properties.
В конфиге (/opt/repl/tungsten/tungsten-replicator/conf/...) на мастере указываем какие фильтры будут использоваться:
replicator.stage.binlog-to-q.filters=dropcomments,filtertables,dbupper
и сам путь до фильтра, и соответственно таблицы которые будут реплицироваться:
replicator.filter.filtertables=com.continuent.tungsten.replicator.filter.JavaScriptFilter
replicator.filter.filtertables.script=/opt/repl/tungsten/tungsten-replicator/filtertables.js
replicator.filter.filtertables.include=idp.abyrvalg,idp.transactions
В данном случае — схема idp и таблицы abyrvalg и transactions.
Убеждаемся, что мастер слушает порт, по которому к нему будет обращаться слейв для забирания thl логов
replicator.master.listen.uri=thl://0.0.0.0:2112/
В replicator.source_id= указываем любое уникальное имя. Проще всего — IP сервера. В моем случае — 192.168.40.3
В конце повествования будут приложены боевые конфиги и разумеется скрипт фильтрации.
Стартуем репликатор на мастере ./replicator start
Проверим его переход в онлайн — ./trepctl status, если офлайн — ./trepctl online
Если статус онлайн — значит все хорошо, он начал складировать у себя бинлоги MySql (по умолчанию, когда они превышают гигабайт — он их сам трет) и thl файлы — собственно что он будет слать слейву, об этом речь еще зайдет чуть ниже. Тут проблем быть не должно.
На слейве соответственно конфиг файл переименовываем в static-<имя схемы>.properties, в моем случае — static-frommysql.properties.
Убеждаемся, что в значении replicator.master.connect.uri=thl://<IP мастера>:2112 точно установлен IP мастера, явки и пароли верны.
replicator.source_id= — опять же любое уникальное значение,
закомментируем replicator.store.thl.storageListenerUri.
Создаем в указанной в конфиге слейва оракла таблицу, соответствующую реплицируемой.
Запускаем слейв — ./replicator start
Если он перешел с состояние по статусу online — все хорошо. Если нет — будет ругаться в логах и статусах.
Можно зайти в созданные схемы на местере и слейве, и обратить внимание — в таблице trep_commit_seqno меняются значения seqno и epoch_number.
Если все ок — можно уменьшить уровень логирования подредактировав wrapper.conf
Немного ухода за пациентом.
На мастере thl логи хранятся сколько указано в конфиге, по умолчанию — день. (replicator.store.thl.log_file_retention=), меняем на нужное нам, на слейве тоже самое. Но если нам срочно потребовалось высвободить место, то придется делать это вручную. Главное — не затереть последний эвент.
На мастере по умолчанию хранятся bin логи в размере не более 1 гигабайта (/opt/repl/relay/...), но для чистки thl вручную на слейве и мастере надо смотреть верхнее и нижнее значение уже записанных эвентов.
Собственно — сей кривой скрипт на мастере и слейве и занимается у меня этим.
#!/bin/sh
cd /opt/repl/tungsten/tungsten-replicator/bin
MINVALUE=`./thl -service frommysql info | grep «min seq# = » | awk '{print $4;}'`
MAXVALUE=`./trepctl status | grep «appliedLastSeqno: » | awk '{print $3;}'`
MAXVALUENEW=`echo "$MAXVALUE-1000" | bc`
./trepctl -service frommysql offline
sleep 10
./thl purge -low $MINVALUE -high $MAXVAskyrimLUENEW -y
./trepctl -service frommysql online
Немного траблшутинга.
Если мы случайно стерли лишнее, либо сеть между серверами лежала длительное время, или случился еще ряд причин, но при коннекте слейв пишет что увы и ах — но он хочет позицию N, а у мастера ее нету, что-нибудь вроде:
INFO | jvm 1 | 2011/11/24 11:32:54 | 2011-11-24 11:32:54,432 [oracle — connector-handler-192.168.39.50] ERROR thl.ConnectorHandler Connector handler terminated by THL exception: Log seek failure: expected seqno=XXXXXXX found seqno=YYYYYYY
(более точно смотрим либо в статусе, либо в логах) — то придется немного подчистить.
Останавливаем репликацию на слейве. Вытираем скопированные thl логи. Обращаем внимание на таблицу trep_commit_seqno. Затираем значения seqno и epoch_number, либо ставим ожидаемые мастером значения, смотря чего он хочет. Запускаем. Дальше придется, конечно, утерянный фрагмент по старинке перегонять из MySql в Oracle (через csv).
Так же, возможно сделать считывание с определенной позиции, см. документацию на официальном сайте, пункты 4.3.x
Конфиг мастера, конфиг слейва и js-скрипт фильтрации:
_http://zalil.ru/32217860
В целом — Tungsten replicator показал себя как очень гибкий и мощный, но не очень хорошо документированный продукт, позволяющий производить репликацию между различными БД под различные задачи.
07.12.2011 18:20+0400