Comments 12
Зачем?
Оно основанно на триггерах или нативных протаколах репликации каждой СУБД?
Поддерживает ли трансформации?
Поддерживает ли трансформации?
Он использует нативную репликацию, привнося дополнительный функционал.
Подробнее об архитектуре можно посмотреть здесь.
Трансформации поддерживаются с помощью фильтров.
Подробнее об архитектуре можно посмотреть здесь.
Трансформации поддерживаются с помощью фильтров.
А расскажите пожалуйста про производительность. При каких нагрузках приходилось держать эту связку? Сколько ресурсов отъедает репликатор?
Для большей наглядности статьи было бы очень здорово:
Ну и спасибо за то, что делитесь опытом!
Для большей наглядности статьи было бы очень здорово:
- скрыть в спойлер типичные шаги установки пакетов в систему
- подробнее описать используемые флаги конфигурации tungsten
- дать небольшую вводную про выбор инструмента, если есть — привести аналоги
Ну и спасибо за то, что делитесь опытом!
О производительности мне сложно судить, пока внедряли в основном на dev-окружениях. Есть один боевой проект, там отставаний не замечено, но и нагрузка средняя.
Ява есть ява, мастер процесс, к примеру, кушает где-то ~500 Мб, слейв чуть меньше. Процессорного времени кушает мало.
Спасибо за замечания, учту.
Ява есть ява, мастер процесс, к примеру, кушает где-то ~500 Мб, слейв чуть меньше. Процессорного времени кушает мало.
Спасибо за замечания, учту.
На моем опыте, по производительности упирались скорее в сеть и диск. Т.е. тунгстен работает следующим образом — он физически копирует себе bin логи MySql и работает с ними, создавая thl файлы команд которые забирает по сети слейв тунгстен и применяет. Соотвественно идет повышенная нагрузка на диск при сильной нагрузке на MySql (бин логи могут занимать очень много и двойная запись тоже отжирает ресурсы), плюс если передавать из многих схем и таблиц, не отсеивая только то что надо, thl могут так же много весить.
Добавим к этому хранение bin логов хотя бы пару дней (что бы в случае падения тунгстена в пятницу ночью вы не потеряли данные для передачи на слейв), и соотв. при высокой нагрузке на БД место будет просто таять.
Решаются эти проблемы на самом деле довольно просто — тунгстен можно поселить на MySql слейве (если правильно помню и не ошибаюсь — надо только включить опцию записи слейв логов).
Добавим к этому хранение bin логов хотя бы пару дней (что бы в случае падения тунгстена в пятницу ночью вы не потеряли данные для передачи на слейв), и соотв. при высокой нагрузке на БД место будет просто таять.
Решаются эти проблемы на самом деле довольно просто — тунгстен можно поселить на MySql слейве (если правильно помню и не ошибаюсь — надо только включить опцию записи слейв логов).
Вооо, а мне как раз надо с нескольких серверов сливать данные на один для последующего анализа, причем далеко не все таблицы и базы. Подскажите он случайно на лету модифицировать не умеет запросы? Например прилетает UPDATE, а мне его надо поменять на INSERT и положить в какую нибудь свою табличку.
Посмотрите документацию, по части фильтров. Думаю все можно сделать.
Давно используем тунгстен для репликации в оракл.
В целом все ок, но бывают и проблемы при больших операциях, когда на слейве тунгстен валится при попытке обработать thl файлы с нехваткой ява памяти ( давали много памяти, но не помогает, увы). В остальном — да, надежно и как Вы выше сказали — фильтры великая вещь и можно отсеивать ненужную информацию и транзакции и преобразовывать как нам угодно.
В целом все ок, но бывают и проблемы при больших операциях, когда на слейве тунгстен валится при попытке обработать thl файлы с нехваткой ява памяти ( давали много памяти, но не помогает, увы). В остальном — да, надежно и как Вы выше сказали — фильтры великая вещь и можно отсеивать ненужную информацию и транзакции и преобразовывать как нам угодно.
Спасибо за статью, прочел месяц назад и только сейчас осознал что мне давно хотелось использовать данные в MySQL, но без map-reduce это было нереально.
А можно наоборот? у вот хочется быстрый mongodb кластер который реплицируется в MySQL. Может такое тунгстен? А если нет то интересно почему.
Sign up to leave a comment.
Репликация данных из MySQL в MongoDB