Бывают случаи, когда нужно менять архитектуру системы на ходу. Возможно вы нашли узкое место в своем проекте или решили, что при текущем темпе роста в скором времени могут возникнуть сложности с масштабированием или отказоустойчивостью. Как раз для таких случаев существует Tungsten Replicator.
Tungsten Replicator — это бесплатное с открытым исходным кодом, приложение написанное на Java, расширяющее функционал репликации СУБД MySQL. Возможности Tungsten широки, это и мульти-мастер репликация, параллельная репликация, гетерогенная репликация данных между MySQL и Oracle, PostgreSQL, MongoDB. В данной статье будет рассматриваться гетерогенная репликация мастера MySQL с подчиненным сервером MongoDB, в качестве ОС будет выступать CentOS 6.5. Читать полностью »
Метка «репликация»
Репликация данных из MySQL в MongoDB
2014-02-04 в 6:29, admin, рубрики: centos-admin.ru, mongodb, mysql, nosql, Tungsten Replicator, Блог компании centos-admin.ru, репликация, системное администрирование, метки: centos-admin.ru, mongodb, mysql, nosql, репликацияРезервная площадка в облаке с использованием vSphere Replication
2013-07-16 в 7:01, admin, рубрики: аварийное восстановление, Блог компании ИТ-ГРАД, виртуализация, ИТ-ГРАД, Облачные вычисления, облачные сервисы, резервное копирование, репликация, метки: аварийное восстановление, виртуализация, ИТ-ГРАД, облачные сервисы, резервное копирование, репликация 
Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки – его можно успешно использовать в качестве резервной!
Простая настройка репликации в PostgreSQL
2013-03-25 в 15:57, admin, рубрики: postgresql, Администрирование БД, базы данных, Песочница, репликация, хранение данных, метки: postgresql, Администрирование БД, базы данных, репликация, хранение данных 
Возникла необходимость быстро и как можно проще организовать репликацию данных с сервера БД на резервный сервер. Простой и понятный способ на просторах Сети так и не нашелся, по этому пришлось по частям собрать информацию, которая и стала этой статьёй.
Решаемая задача. Исходные данные
Итак, имеем сервер БД, с которым работают клиенты, и резервный сервер, на который надо настроить репликацию с основной базы данных.
В моём случае используется PostgreSQL 9.2.1, который установлен на обоих серверах и поддерживает потоковую репликацию. Предположим что база данных на основном сервере развернута и работает, на резервном только установлен, но не настроен PostgreSQL. Для примера возьмем IP-адрес 192.168.1.1 за адрес основного сервера, IP-адрес 192.168.1.2 — за адрес резервного.
Читать полностью »
Системы хранения данных: как медленно, но верно они отвязываются от железа
2013-02-14 в 7:13, admin, рубрики: disaster recovery, EMC, авария, Блог компании КРОК, виртуализация, ит-инфраструктура, миграция, переезд, репликация, синхронизация, СХД, хранение данных, цод, метки: disaster recovery, EMC, авария, виртуализация, миграция, переезд, репликация, синхронизация, СХД, хранение данных, цод 
Авария в первом дата-центре и автоматический перезапуск сервисов в другом
Виртуализация — одна из моих любимых тем. Дело в том, что сейчас можно практически полностью забыть про используемое железо и организовать, например, систему хранения данных в виде «логического» юнита, который умеет взаимодействовать с информацией по простым правилам. При этом все процессы между виртуальным юнитом и реальным железом в разных ЦОДах лежат на системе виртуализации и не видны приложениям.
Это даёт кучу преимуществ, но и ставит ряд новых проблем: например, есть вопрос обеспечения консистентности данных при синхронной репликации, которая накладывает ограничения на расстояния между узлами.
К примеру — скорость света становится реальным физическим барьером, который не даёт заказчику поставить второй ЦОД дальше 40-50, а то и меньше, километров от первого.
Но давайте начнём с самого начала — как работает виртуализация систем хранения, зачем оно всё надо, и какие задачи решаются. И главное — где конкретно вы сможете выиграть и как.Читать полностью »
Active Directory Replication Status Tool: Новая утилита от Microsoft для определения статуса репликации AD
2012-08-06 в 11:40, admin, рубрики: active directory, Блог компании NetWrix, репликация, системное администрирование, утилита, метки: active directory, репликация, утилита 
Шон Дьюби, MVP в Directory Services, сделал обзор новой утилиты от Microsoft ADREPLSTATUS, предназначенной для определения статуса репликации. Как новая утилита работает и почему Вам все равно придется пользоваться старым-добрым REPADMIN — об этом Вы можете узнать подробнее под катом.
Читать полностью »
Репликация из OLTP в OLAP базу данных
2012-06-13 в 11:35, admin, рубрики: mysql, Vertica, Администрирование баз данных, репликация, метки: mysql, Vertica, репликацияМой друг Роберт Ходжес на днях опубликовал статью про репликацию из OLTP в OLAP базу данных (а именно, из MySQL в Vertica), которую его компания построила на своем продукте Tungsten. Самое интересное, это преобразование данных, которое происходит в процессе репликации. Подход достаточно общий, и может быть использован и для других систем.
Обычный подход к репликации — это синхронный или асинхронный перенос бинарного лога с одной базы данных (мастер) на другие (слейвы). В бинарном логе строго последовательно записываются все операции, которые модифицируют данные. Если его «проиграть» на другой системе с той же начальной точки, то должно получиться точно такое же состояние данных, как и на исходной. «Проигрывание» происходит по одной операции или по одной транзакции, то есть очень маленькими кусочками.
Этот подход плохо работает с OLAP-специфичными, и особенно, колонко-ориентированными базами данных, которые хранят данные физически не по строкам, а по колонкам. Такие базы данных оптимизированы на запись, чтение и сортировку больших массивов данных, что типично для аналитических задач, но не на маленькие операции на единичных записях, потому что любая операция затрагивает много колонок, которые физически хранятся в разных файлах (а иногда и разных дисках). Хуже всего обстоит дело с изменением данных. Конечно, все базы данных поддерживают стандарт SQL и оператор UPDATE, но на физическом уровне он, как правило, транслируется в то, что обновляемая запись помечается как удаленная, а вместо нее вставляется измененная копия. Потом, когда-нибудь, «сборщик мусора» перетрясет таблицу и удаленные записи удалятся навсегда. Помимо плохой эффективности, отсюда следует, что частые удаления и обновления приводят к «засорению» базы данных, что снижает ее производительность в том числе и на чтение.
Роберт предложил, как мне кажется, новый, хотя и естественный подход к решению проблемы репликации данных для таких случаев. Бинарный лог преобразуется в последовательность частично упорядоченных множеств операций типа DELETE/INSERT для каждой таблицы, причем, так слово «множество» подразумевает, что «одинаковые» в некотором смысле операции достаточно сделать один раз. Поясню чуть подробнее.
Читать полностью »
Эволюция архитектуры: от «самописных» сервисов к HandlerSocket
2012-04-12 в 9:16, admin, рубрики: badoo, mysql, replication, баду, Блог компании Badoo, Веб-разработка, высокая производительность, репликация, метки: badoo, mysql, replication, баду, репликация 
Сегодня мы расскажем о том, как в Badoo изменился подход к проектированию нагруженных “key-value” сервисов. Вы узнаете, по какой схеме такие сервисы создавались нами несколько лет назад (использование БД в качестве репозиториев и специализированного демона как интерфейса к данным), с какими трудностями мы при этом столкнулись и к какой архитектуре в результате пришли, разрешив появившиеся проблемы.
Читать полностью »
PostgreSQL / Отказ мастера в PostgreSQL-кластере: как быть?
2012-02-10 в 0:11, admin, рубрики: failover, postgresql, replication, репликация, метки: failover, postgresql, replication, репликация Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами.
1. Применение триггер-файла.
В мануале по настройке репликации сказано, что в recovery.conf помимо прочего можно(и нужно) указать параметр trigger_file. Здесь всё просто — как только вы создадите на реплике файл, указанный в этом параметре, PostgreSQL прервёт процесс восстановления(вЧитать полностью »