Мы — долго запрягаем, быстро ездим, и сильно тормозим.
|
||||||||||||||||||||||||||||||||||||||||||||||||||
www.lissyara.su
—> статьи
—> FreeBSD
|
BSD1 re0 ip: 10.10.10.10 BSD2 re0 ip: 10.10.10.20 |
Теперь приступим к установке MySQL, я выбрал версию 5.1, кто-то может выбрать другую, более новую, но меня устраивает такая! Для начала обновим порты, как это сделать? Вы наверняка знаете, если не знаете, то найдёте уйму материала, на данном замечательном ресурсе…
1. Устанавливаем на обоих серверах, MySQL сервер, я делал это так:
|
Я выбрал кодировку koi8r, вы можете указать другую, например, cp1251, но я сторонник koi8r!
Создаём MySQL базу:
|
Присваиваем правильные права:
|
Создаём файл для логов с нужными правами:
|
Копируем конфиг:
|
2. Когда вы дошли до этого этапа, можно приступить к настройке первой фазы репликации Master + Slave (Ведущий + Ведомый), в нашем случае Master будет (BSD1), а Slave будет (BSD2).
Начнём редактировать конфиг Master (BSD1).
my.cnf:
|
Обратите внимание – это очень важно, чтобы у вас в конфиге не повторялись строки, такие как:
|
Иначе может ничего не получится, в лучшем случае будет работать с косяками, если строки где-то повторяются, закомментируйте их!
Также обратите внимание на такие строки, как:
|
3. Поработаем с конфигом Slave(BSD2).
my.cnf:
|
Ещё раз напоминаю, чтобы проверяли, не повторяются ли строки в конфигах!!!
|
4. На обоих серверах добавляем автозагрузку MySQL в rc.conf:
|
Запускаем на обоих серверах MySQL:
|
Проверяем работает ли:
|
Обратите внимание, чтобы MySQL слушал во всех направлениях и чтобы не получилось так, что он будет слушать localhost или какой-то отдельный ip. Нам нужна будет репликация, поэтому MySQL должен слушать как минимум в сторону кроссовера или лучше во всех направлениях, а кто боится о безопасности, то заткните при помощи FireWall те места!
5. Настраиваем root пользователя на обоих серверах:
|
Заходим:
|
На сервере Master (BSD1) добавляем пользователя для репликации Slave:
|
Перезапускаем привилегии:
|
На сервере Slave (BSD2) стартуем Slave режим:
|
Проверяем стал Slave(BSD2) сервер, в режим Slave?
|
Если строки:
|
Показывает состояние Yes, значит всё получилось!
Режим Master + Slave работает!
6. Тестируем:
На сервере Master (BSD1), проверяем состояние Master:
|
Должно быть примерно так:
|
Отсюда мы видим, что две базы игнорируют репликацию, а одна подвергается!
Создаём базу на сервере Master:
|
Проверяем на сервере Slave:
|
Видим, что на втором сервере Slave также появилась база testdb!
7. Этот пункт можно пропустить, но я бы сделал так - вносим полезные изменения в MySQL сервера, причем это нужно сделать на обоих серверах!
Удаляем test базу:
|
Теперь редактируем mysql базу:
|
Смотрим, что в таблице пользователей:
|
У Master будет так:
|
А у Slave вот так:
+-----------+------+-------------------------------------------+
| Host | User | Password |
+-----------+------+-------------------------------------------+
| localhost | root | *28B7B09A25EC723332B51CF8FD7286F9BD8CFB44 |
| BSD2 | root | |
| 127.0.0.1 | root | |
| localhost | | |
| BSD2 | | |
+-----------+------+-------------------------------------------+
Такой вид - это не есть гуд!
Грохаем ненужных пользователей:
|
Разумеется, что для сервера BSD2, мы BSD1 заменим на BSD2!
|
Вот теперь есть гуд для Master:
|
И для Slave:
|
Для чистоты можно и в таблице db навести марофет:
|
Перезапускаем привилегии:
|
Ну вот мы и справились с первой фазой, с настройкой и оптимизацией!
Конец первого акта, антракт, идём пить чай, кофе, капучино, приставать к нетрезвым женщинам!
*********** АНТРАКТ ***********
Акт второй:
Master (BSD1) + Slave (BSD2) мы осуществили, теперь нужно организовать симметрично
Master (BSD2) + Slave (BSD1) для полного режима Master + Master!
1. Приступим! Правим конфиг Slave (BSD1).
Добавляем в my.cnf:
|
2. Затем правим конфиг Master(BSD2).
Добавляем в my.cnf:
|
А также добавляем на Master (BSD2) учётную запись репликации:
|
А теперь перезапускаем оба сервера:
|
Итак, теперь помолимся пару секунд богам FreeBSD, можно в жертву принести компашку с Windows! :-)
Проверяем, на обоих серверах делаем:
|
И если мы правильно молились, то увидим на обоих серверах:
|
Если у вас также, то боги вас услышали!
3. Тестируем:
На сервере Master (BSD2) добавляем таблицу в базе testdb:
|
Проверяем на сервере Master (BSD1), добавилась ли таблица?
|
Теперь останавливаем любой из серверов, к примеру, Master (BSD1), а на сервере Master (BSD2) добавляем данные:
|
|
Запускаем остановленный сервер:
|
Проверяем, добавилась ли новая информация?
|
Работает! Можно ещё долго тестировать… Ну, это вы сами сможете сделать.
Примечания!
0. Будьте внимательны с нетрезвыми женщинами!
1. Будьте внимательны с конфигами, проверяйте, чтобы строки не повторялись!
2. Если вы переделываете уже существующий MySQL сервер, вам придётся лучше забекапить базы, грохнуть все файлы в директории /var/db/mysql/, разумеется папки с базами можно не трогать! Иначе могут быть косяки с репликацией!
3. Если вдруг ошиблись или поменяли ip адреса серверов, когда поменяете в конфиге ip репликации, то ещё надо будет грохнуть файл:
|
4. И обязательно нужно настроить правильно время на обоих серверах! Время должно чётко работать согласно временным поясам, лучше всего это организовать через ntpd демона, на данном ресурсе имеются статьи о том, как это сделать!
*************** КОНЕЦ ***************
размещено: 2010-04-14,
последнее обновление: 2015-04-07,
автор: fox
pythonchik, 2010-04-13 в 23:39:17
пардон, но эпилог в начале статьи....
может все-таки эфиграф?
fox, 2010-04-14 в 1:31:53
Сори, ачипятка "Пролог"... Пофиксел!
Vosi, 2010-04-14 в 15:45:58
не забудь
auto-increment-offset = 2 на одном и
auto-increment-offset = 1 на другом (или наоборот)
для того чтоб проблем с правймари небыло
а еще, чтоб поднять мастер-мастер с сингла достаточно:
1. остановить синг
2. настроить май.кнф на сингле для слейв
3. удалить все бинлоги итп, кроме ибдата, май.кнф, и диров с таблицами на сингле
4. настроить мак.кнф на новом для слейв
5. скопировать ибдата+диры с таблицами с сингла на новый
6. стартануть сингл
7. стартануть новый
смотреть еррор логи там и там
mgyk, 2010-04-19 в 2:32:29
koi8-r это круто
h, 2010-04-19 в 13:56:48
master-host = 10.10.10.10
master-user = replication
master-password = slavepass1
master-port = 3306
вот это в конфиге не нужно. один раз стартуете репликацию из mysql и данные о подключении сохраняются в master.info.
плюс в том, что для того чтобы сменить настройки подключения не нужно править my.cnf и не нужно перезапускать mysqld.
смотрите high performance mysql.
playnet, 2010-04-23 в 19:34:20
Если кто смотрел "папский городок": все фразы с "!" на конце должны звучать как у Рихтера. :)
Использовать сейчас в основе что кои8, что цп1251... это некрофилия.
А ошибок действительно много, в тч. логических...
5chme1, 2010-08-27 в 16:19:31
хорошая статья. в phpmyadmin3 тоже по моему можно репликацию делать
fox, 2010-08-27 в 18:52:02
Видал я там какие то параметры но не стал разбиратся, вообще мне понадобилась репликация из-за двуш люзов в инет, на обоих стоит связка squid+sams, вот захотелось машино независемый шлюз организовать (типа класстер но не кластер), и разумеется база MySQL служет конфигом и стаитистекой...
MK, 2011-01-02 в 11:34:13
Статья хороша, но есть вопрос, как будет вести себя репликация мастер-мастер на нагруженой бд? при балансировки нагрузки? в случае если сам добавил одну запись на одном сервере и она реплицировалась на второй это одно, но когда в единицу времени добавляется запись на 1м сервере и на 2м сервере, как будет себя вести данная связка? на сколько я понимаю блокировки нету? (пробовали сделать так, отключить один сервер добавить в него запись, отключить второй сервер, в него добавить другую запись в туже таблицу и включить их для синхронизации).
fox, 2011-01-04 в 5:37:02
Я думаю будет всё нормально, точнее всё будет упираться в железо!
У меня в таком режиме постоянно два сервера одновременно бросают записи с прокси, база за год выросла на 18 миллионов строк, пока не наблюдал проблем занимает 8 гиг…
Ну нужно пробовать в Вашем случае, дело может быть индивидуальным…
Dmitri, 2011-05-31 в 0:32:26
Спасибо, помогли.
Mox, 2011-08-26 в 14:56:52
А еще втыкаем в http://dev.mysql.com/doc/refman/5.5/en/replication-rules.html
Не стоит пользоваться binlog-ignore-db и binlog-do-db в качестве фильтра. Только replicate-* на стороне слэйва
Mox, 2011-08-26 в 17:23:15
+ читаем о вреде binlog-ignore-db и binlog-do-db http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/
ttys, 2011-08-28 в 16:30:29
сейчас столкнулся с тем что даже RAC Oracle не может нормально отработать падение одного из серверов, тоесть те транзакции которые были открыты отваливаются.
ИМХО из бесплатных решений вряд ли, что подойдёт для продакшн
выход базу располагать на сторадже с платным решением
суперадмин, 2013-03-13 в 15:27:16
ttys,
про оракл: а разве так не должно разве и быть? он оставляет закомиченные сессии, а все не закомиченно откатывается.
ttys, 2013-03-13 в 16:19:23
суперадмин,
не должно
он должен передать всё второму, что то типа рейд 1
и в платных вариантах это так и работает
Этот информационный блок появился по той простой причине,
что многие считают нормальным, брать чужую информацию не уведомляя автора
(что не так страшно), и не оставляя линк на оригинал и автора — что более существенно.
Я не против распространения информации — только за. Только условие простое — извольте
подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой,
незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.
© lissyara 2006-10-24 08:47 MSK
Комментарии пользователей [16 шт.]