Как стать автором
Обновить

Комментарии 44

Очень подробно и понятно написано, спасибо
А что на тему ротации бинарных логов с которых ведется постоянно реплика?
MySQL их сам крутит или нужно самому следить как-то за этим?
Переменная expire_logs_days задает количество дней сколько хранятся бинарные логи.
Вам нужно следить только за наличием свободного места под логи.
Некоторые момента освещенны не совсем корректно.

Например утверждения:
1. «Если откажет мастер, запросы записи можно перевести на реплику (после того, как мастер будет восстановлен, он может принять на себя роль реплики).»

2.«для осуществления полнотекстового поиска мы можем на реплике использовать тип таблицы MyISAM, несмотря на то, что мастер будет использовать InnoDB»

при их совместном использовании могут привести к плачевным результатам в работе некоторых сервисов на проекте.
А можно разъяснить поподробнее? Заинтересовал момент о «плачевных результатах».
Ну очевидно же, мастер валится, переводим запись на реплику, а там MyISAM без поддержки транзакций.

Ну это как пример.
Трюк с разными типами таблиц, индексов и на то и трюки, что надо с большой осторожностью их выполнять :) И предварительно лучше подстелить соломки — т.е. сначала настроить полноценный резерв для мастера, а потом уже делать реплики «со отклонениями».
Я это понимаю, я просто «разъяснил поподробнее» предыдущему откомментировавшему :)
Хотелось бы отметить, что репликация в mysql 5.0.x и более ранних версиях позволяет существенно увеличить производительность общей системы — используется так называемый SBR, в котором реплицируются не изменения, а sql-запросы, и по сути, нагрузка на мастер и на slave сточки зрения изменения данных — одинаковая.
В mysql 5.1.x появилась row-based replication, но я еще боюсь ставить 5.1, видя какие баги там бывают :)
Row-based replication конечно тяжелее, но позволяет пофиксить фичи, которые криво работают в схеме SBR. Например, в «традиционном» мускуле если на реплике (почему-то :) сбито системное время, колонки типа TIMESTAMP на мастере и слейве будут отличаться. К счастью, таких проблем не так много, и их список можно найти в документации.
Да, я знаю :) Но что касается конкретной проблемы с timestamp'ом — сервер без ntp — не сервер :)
Реплика может отставать на сутки, а Вы про ntp…
Это уже не лечится :)
Немного сложновато для первого понимания, но очень пригодится в расширении.

>> Для начала настроим MySQL на второй реплике и убедимся, что мы внесли нужные параметры в конфиг:
>> server-id = 2

разве для реплики-2 server-id должен быть 2? Он же должен быть уникальным, значит 3…

Да, спасибо, что обратили внимание. Поправил.
А Вы не путаете репликацию со standby? Или в мире MySQL это устоявшаяся терминология?
Хотя согласен — это репликация.
Вопрос тогда такой — в MySQL есть возможность репликации отдельных таблиц и/или materialized view?
используем репликацию давно уже в нашем програмном обеспечении для обновления учетных записей пациентов больших госпиталей. делаем реплики базы данных на ноутбуках докторов чтоб они могли работать вне оффиса, а потом тиражировать изменения в главную базу. очень удобно.
еще один способ залить данные с master на slave без остановки мастера существует, хоть и устаревший:
запрос
LOAD DATA FROM MASTER;
на slave

в 5.0.х еще рабоатет, хоть MySQL постоянно напоминают о том, что способ устаревший и будет выкинут за ненадобностью.
На мастере понятно лочатся таблицы, но автоматически
А к какому серверу коннектиться из скриптов? (К мастеру или реплике?)
Использовать несколько соединений. При чтении обращатся к рекпликам, а при записи в мастеру.
А если у меня будет 10 slave серверов, то выбирать рандомно? Думаю что это не очень эффективно, наверно есть более оптимальное решение?
Ну почему же, например: несколько серверов будут отвечают за погрузку допустим комментариев. Для медленных «ресурсоёмких» запросов будет пара мощных серверов. И несколько для всего основного. Есть «тип коннекта» который случайно выбирает один из «свободных» серверов своего типа и используется там где это необходимо.
Для этого существует балансировка нагрузки. Идея в следующем. Есть некая сущность, например специальное ПО для циски, которая владеет информацией о загруженности серверов. Из своих приложений обращаемся к этой сущности, а она сама уже определяет какому серверу перенаправить наш запрос.
есть еще такая штука как MySQL Proxy
клиенты подключаются к ней, а она уже фильтрует, балансирует и тд
Удачно сделал репликацию используя file system snapshots на freebsd.
Создание снапшота 700гб партиции с 400гб данными — заняло 10 минут.
После — включение бинарных логов, копирование данных со снапшота на слейв и запуск репликации.
Для версий mysl4.x кроме SET GLOBAL read_only = OFF; нужно ещё делать UNLOCK TABLES;
Ошибка в CHANGE MASTER TO MASTER_HOST = «192.168.1.101 », MASTER_USER = «replication », MASTER_PASSWORD = «password », MASTER_LOG_FILE = «mysql-bin.000016 », MASTER_LOG_POS = 501; перед закрывающимися кавычками не должно быть пробела. Например MASTER_HOST = «192.168.1.101 „ нужно заменить на MASTER_HOST = “192.168.1.101»
Настроив генерацию бин-логов в результате получил резкое снижение производительности системы в целом (как понимаю, из-за частого обращения к дисковому массиву)
Мож кто подскажет, как данную проблему побороть? Поскольку, как я понимаю, писать логи в ОЗУ не выход…
Хорошая статья, получилось настроить по ней.
Единственное замечание — GRANT replication slave ON «testdb».* сейчас уже не прокатит, должно быть GRANT replication slave ON *.*. Ну и про пробелы перед закрывающими кавычками выше уже написали.
CHANGE MASTER TO MASTER_HOST = "192.168.1.101 ", MASTER_USER = "replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE = "mysql-bin.000003 ", MASTER_LOG_POS = 98;

Пробелы после значений нужны? У меня, из-за них час времени ушел, чтобы понять, почему я не могу подключиться к мастеру. Решил пробелы убрать и все заработало.
Там в последних абзацах перед «ЗАКЛЮЧЕНИЕ» подправьте наверное — вместо mysql@master> должно быть mysql@replica>

По идее и так понятно все, но вдруг у кого-то затык будет.

Я про:

mysql@master> CHANGE MASTER TO MASTER_HOST = «192.168.1.102 », MASTER_USER = «replication », MASTER_PASSWORD = «password », MASTER_LOG_FILE = «mysql-bin.000001 », MASTER_LOG_POS = 61;

mysql@master> start slave;
спасибо за статью!
например на уровне php в случае использования реплик, придется создавать 2 mysql коннекта и обращаться к разным серверам в зависимости от запроса, я правильно понимаю?
Да.
И при рокировке master-slave, если старый мастер уже когда-то работал слейвом, скорее всего, потребуется сделать reset slave, чтобы он забыл старые значения, иначе репликация не стартует.
replicate-do-db = testdb

В настройках мастера replicate-do-db не нужно. Нужно binlog_do_db. А вот в слейве replicate-do-db. В статье куча мелких ошибок, которые неплохо замедляют настройку по ней при отсутствии опыта.
GRANT replication slave ON ’testdb’.* — не верно… replication можно дать только на все базы *.*
Иногда возникают ошибки репликации — например, попытка вставить строку с таким значением уникального поля, которое уже есть в таблице. Вообще говоря, после этого нельзя быть уверенным в консистентности данных на реплике и лучше бы перезалить адекватную базу с мастера, но если ошибки происходят в таблицах вроде хранилищ кеша или сессий и нет желания перезапускать репликацию, а хочется просто пропустить ошибку и двигаться дальше, можно дать следующую команду:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

— т. е. пропустить одну ошибку репликации (можно и больше — например, если сбоит операция, которая приводит автоинкременту — фактически это две операции). Делать лучше на выключенном слейве, т. е. полностью команда может выглядеть так:

STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; SHOW SLAVE STATUS;
Статья 2009 года, может быть тогда таких возможностей не было.
Но для того, чтобы снять дамп вовсе не обязательно ставить лог на запись, по крайней мере для innodb достаточно добавить ключи к mysqldump --single-transaction (снимаем «копию» моментально снапшота) и --master-data (добавить в дамп позицию бинлога в момент начала дампа)
Спасибо за статью
Если не сложно, ответьте на вопрос:
Что делать когда в репликации Master-Slave, Slave сервер нельзя поставить в read-only, по причине отказа работы движков DLE и SMF на этом сервере, в то время как на Slave сервере было сделано изменение в базе и теперь базы различаются?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории