|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Доброго времени суток. Ребят, есть 2 физических сервера в разных ДЦ в разных городах
на них работает 1 сайт, как бы зеркала, БД MySql настроена на репликацию Master-Master но время от времени бинлоги сбиваются и базы рассинхронизируются, скажите как можно избежать рассинхрона или в случае возникновения в автоматическом режиме синхронизировать базы.
Заранее благодарю за полезные советы.
Неактивен
Настройка master-master — это целое искусство. Нужно запретить выполнять запросы,
которые разламывают репликацию, запросы, которые некоммутативны, пересечения id
и прочее. В каждом конкретном случае надо смотреть, почему разбилась репликация.
Автоматическое восстановление — это не то, что Вы хотите, т.к. надо смотреть глазами
и думать головой каждый раз. Однотипные ошибки можно игнорировать (--slave-skip-error),
но велик шанс, что разломаете вообще всё. Универсальный способ восстановления реп-
лики — ее переливка с мастера. Это можно делать в автоматическом режиме. Но, наверное,
не очень целесообразно 
Неактивен
paulus написал:
Нужно запретить выполнять запросы, которые разламывают репликацию, запросы,
а какие именно запросы это могут быть? никаких сложных запросов обычно не бывает, обычные выборка, обновление, вставка и удаление..
paulus написал:
которые некоммутативны,
это какие? 
paulus написал:
пересечения id
точно исключено, поскольку автоинкремент равен 10, повторения айди не встречалось ниразу
Если позволите, еще пару вовпросов:
1. Могут ли разрушить репликацию следующие проблемы: to many connections или временная потеря связи со вторым сервером?
2. Можно ли в ручном или автоматическом режиме синхронизировать базы записывая в них только изменения, а путем копирования дампа одной из баз, ведь в таком случае теряются данные. Спасибо за ответы.
Неактивен
Некоммутативный запрос, например,
INSERT INTO a SELECT ... FROM b;
Очевидно, он зависит от того, успеет приехать строка в b из другого мастера
до запроса, или не успеет.
ID — это единственное, что решается всегда
1. Я могу представить себе ситуацию, когда это может быть так (например,
при too many connections пришел кто-нибудь злобный и убил большой update,
который успел обновить только половинку таблички MyISAM). Потеря связи —
тоже могу, в 5.0.32 была бага, при которой при некоторых хитрых обрывах
связи рушилась репликация.
2. Репликация так и работает — применяет изменения одного сервера на
другом. И разваливается она тогда, когда автоматически это не срабатывает.
Неактивен
Спасибо вам за консультацию) сейчас активно сражаемся с рассинхронами бд, т.е. с развалом реплики((
paulus написал:
2. Репликация так и работает — применяет изменения одного сервера на
другом. И разваливается она тогда, когда автоматически это не срабатывает.
да но вот вопрос как после развала снова синхронизировать БД без потери информации)) ведь если одну бд заменять другой часть информации все равно неизбежно теряется и здесь лишь остается выбрать какую часть потерять..
Реально ли построить кластер если сервера физически в разных ДЦ? или может есть другой более рациональный способ использовать второй сервер для ускорения работы основной БД и всего проекта вцелом?
Неактивен
Если данные совсем побились, то можно, например, взять данные с одного
сервера, предварительно налив на него бинлоги другого (тогда у Вас полу-
чится нечто третье, что будет содержать оба набора данных), и получив-
шегося зверя скопировать на реплику. Но, конечно, это не решит основную
проблему изменения кода так, чтобы он поддерживала мультимастер.
Кластер в разные ДЦ натянуть реально, но работать он не будет. Точнее,
будет, но *чрезвычайно* медленно из-за того, что ему нужно будет синхрон-
но сохранять информацию. Более того, Вы не сможете заставить его выбирать
локальную датаноду — иногда он будет бегать и на чтение за данными в
другой ДЦ.
Если код модифицировать нельзя — обычно оставляют одного мастера. Если
можно — можете попробовать допилить код до мультимастерного или, например,
сделать несколько независимых шардов (тогда изменения кода незначительны —
выбирать данные из двух шардов, а писать только в свой, но задачу локального
мастера вы решите).
Неактивен
Страниц: 1
