После настройки MySQL репликации master-master, следующий логический шаг это настройка проверки этой системы. Читая туториалы по интернету стало ясно, что подобная репликация — дело популярное, а слетает оно на раз два три. Поэтому решил вставить проверку — а работает ли репликация до сих пор, или что-нибудь произошло и все слетело.
Первые же несколько гугл запросов показали, что верить «SHOW SLAVE STATUS\G» нельзя: Штука хорошая, но врет часто и помногу. Немного подумав, я пришел к следующему решению:

Итак, в начале несколько слов, а-ля предисловие. Данный мануал не претендует на истину в первой инстанции и на построчное руководство. Скрипты можно написать куда лучше. Команды — на момент прочтения могут звучать уже по другому (даже на момент написания документация на сайте разниться с реальными командами). Многое в скриптах сделано под рутом, что в целом тоже не правильно, но для «что бы заработало а потом поправить» — оставил пока что так. Ответы на базовые вопросы по настройке Вы найдете в документации на сайте tungsten-а (http://code.google.com/p/tungsten-replicator/).

Задача:

Возникла необходимость в репликации с MySql (5.5) на Oracle (11.2) на сервере с CentOS 5.5. При чем не всего-всего, а только больших таблиц, очень-очень быстро наполняющихся и связанных со статистикой. Добавим к этому, что на сервере MySql наблюдаются проблемы с местом, и как вывод — фильтрация репликации должна происходить на нем. Ну, и при необходимости — сразу подчищаться все возможные временные файлы, опять же по причине места, на обоих серверах.

Предисловие.

Понадобилось сделать репликацию несколькими мастер-серверами с mysql, чтобы данные со всех них грузились на один слэйв-сервер. Готового решения стандартными средствами не нашлось. Но так как проблема оставалась актуальной, со временем подоспел немного усложненный, но работоспособный вариант c использованием средств самой mysql.

Со времени запуска проекта прошло некоторое время и настало время наращивать вычислительные мощности для работы приложения. Было принято решение построить для этого кластер, который в дальнейшем можно будет легко масштабировать. Таким образом нам надо настроить кластер для распределения запросов между серверами.

Для этого мы будем использовать 4 сервера на Linux CentOS 5.5, а так же Apache, Tomcat6, mod_jk, Heartbeat.
web1, web2 сервера — для распределения запросов средствами Apache и отказоустойчивости средствами Heartbeat. tomcat1, tomcat2 сервера — Tomcat сервера для Java-приложения.

В этой статье я расскажу, как настроить репликацию баз данных для PostgreSQL. Для экспериментов будем использовать дистрибутив линукса CentOS 5.3, хотя это не принципиально. будем использовать версию PostgreSQL 8.4.7 и SymmetricDS-2.2.2.

Что такое репликация?

По сути, это механизм автоматической синхронизации содержимого баз данных, работающих на разных серверах. В результате репликации эти базы данных содержат абсолютно идентичные данные. Это нужно например для того, чтобы обеспечить отказоустойчивость системы (в случае падения первого сервера баз данных в работу вступает второй), или чтобы осуществить балансировку нагрузки — разных клиентов могут обслуживать разные сервера.

Для репликации нужно как минимум два сервера баз данных, поэтому готовим два одинаковых сервера с базой данных PostgreSQL на каждом. У первого будет IP адрес 10.0.2.20, у второго — 10.0.2.21, у обоих гейтвей 10.0.2.2.
Можно обойтись виртуальной машиной, например VirtualBox, создать в ней два виртуальных сервера и запустить их на своем собственном компе.

В приведенных командах первым символом будет стоять знак # либо $, эти знаки означают, что команда запускается из-под root или из-под обычного пользователя, соответственно.
Итак, какие действия нужно предпринять: