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

Чтобы обеспечить возможность восполнения для реплики, которая была отключена, нельзя удалять файлы бинарного журнала из источника, которые содержат информацию, которая еще не была реплицирована на реплики. Асинхронная репликация может работать только в том случае, если реплика может продолжить чтение бинарного журнала с той точки, где она последний раз читала события.

Да, работа сети должна быть включена на источнике и реплике. Если работа сети не включена, реплика не сможет подключиться к источнику и передать бинарный журнал. Убедитесь, что системная переменная skip_networking не включена в конфигурационном файле ни для одного из серверов.

Проверьте столбец Seconds_Behind_Master в выводе из SHOW REPLICA | SLAVE STATUS. См. Раздел 19.1.7.1, «Проверка состояния репликации».

Когда поток SQL репликации выполняет событие, считанное из источника, он изменяет свое собственное время на метку времени события. (Вот почему TIMESTAMP хорошо реплицируется.) В столбце Time в выводе из SHOW PROCESSLIST, количество секунд, отображаемых для потока SQL репликации, — это количество секунд между меткой времени последнего реплицированного события и реальным временем машины-реплики. Вы можете использовать это для определения даты последнего реплицированного события. Обратите внимание, что если ваша реплика была отключена от источника в течение одного часа, а затем снова подключилась, вы можете сразу увидеть большие значения Time, такие как 3600, для потока SQL репликации в SHOW PROCESSLIST. Это происходит потому, что реплика выполняет инструкции, которым один час. См. Раздел 19.2.3, «Потоки репликации».

Используйте следующую процедуру:

В настоящее время репликация MySQL не поддерживает никакого протокола блокировки между источником и репликой для гарантии атомарности распределенного (межсерверного) обновления. Другими словами, клиент A может внести обновление в co-источник 1, и тем временем, прежде чем оно распространится на co-источник 2, клиент B может внести обновление в co-источник 2, которое заставит обновление клиента A работать иначе, чем на co-источнике 1. Таким образом, когда обновление клиента A дойдет до co-источника 2, оно создаст таблицы, которые отличаются от того, что у вас есть на co-источнике 1, даже после того, как все обновления из co-источника 2 также распространились. Это означает, что не следует связывать два сервера вместе в двунаправленном отношении репликации, если вы не уверены, что ваши обновления могут безопасно происходить в любом порядке, или если вы каким-либо образом не обрабатываете неправильно упорядоченные обновления в клиентском коде.

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

Настройте один сервер в качестве источника и направьте все записи на него. Затем настройте столько реплик, сколько у вас есть бюджет и места в стойках, и распределите чтения между источником и репликами. Вы также можете запустить реплики с параметром , включить системную переменную low_priority_updates и установить системную переменную delay_key_write в ALL, чтобы получить повышение скорости на стороне реплики. В этом случае реплика использует не транзакционные таблицы MyISAM вместо таблиц InnoDB, чтобы получить большую скорость, исключив накладные расходы на транзакции.

См. руководство по использованию репликации в качестве решения для горизонтального масштабирования, Раздел 19.4.5, «Использование репликации для горизонтального масштабирования».

Репликация MySQL наиболее полезна для системы, которая обрабатывает частые чтения и редкие записи. Теоретически, используя настройку с одним источником и несколькими репликами, можно масштабировать систему, добавляя больше реплик, пока не исчерпается пропускная способность сети или нагрузка обновлений не станет такой большой, что источник не сможет её обработать.

Чтобы определить, сколько реплик можно использовать, прежде чем дополнительные преимущества начнут снижаться, и насколько можно улучшить производительность сайта, необходимо знать ваши шаблоны запросов и эмпирически определить взаимосвязь между пропускной способностью чтения и записи на типичном источнике и типичной реплике путём тестирования. Приведённый здесь пример показывает довольно упрощённый расчёт того, что можно получить с репликацией для гипотетической системы. Пусть reads и writes обозначают количество чтений и записей в секунду соответственно.

Допустим, нагрузка системы состоит из 10% записей и 90% чтений, и мы определили путём тестирования, что reads составляет 1200 - 2 * writes. Другими словами, система может выполнять 1200 чтений в секунду без записей, средняя запись в два раза медленнее средней записи, а взаимосвязь линейная. Предположим, что источник и каждая реплика имеют одинаковую ёмкость, и у нас есть один источник и N реплик. Тогда для каждого сервера (источник или реплика):

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1) (чтения разделены, но записи реплицируются на все реплики)

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N + 1))

Последнее уравнение указывает максимальное количество записей для N реплик, учитывая максимальную возможную скорость чтения 1200 в секунду и соотношение девять чтений на одну запись.

Этот анализ приводит к следующим выводам:

Эти вычисления предполагают бесконечную пропускную способность сети и игнорируют несколько других факторов, которые могут быть существенными для вашей системы. Во многих случаях вы не сможете выполнить вычисление, подобное тому, которое только что было показано, чтобы точно предсказать, что произойдёт в вашей системе, если вы добавите N реплик. Однако ответы на следующие вопросы помогут вам определить, улучшит ли и насколько репликация производительность вашей системы:

Способ реализации избыточности полностью зависит от вашего приложения и обстоятельств. Решения высокой доступности (с автоматическим переключением) требуют активного мониторинга и либо пользовательских скриптов, либо инструментов сторонних разработчиков для обеспечения поддержки переключения от исходного сервера MySQL к реплике.

Для ручного управления процессом вы должны иметь возможность переключаться с отказавшего источника на предварительно настроенную реплику, изменив ваше приложение для работы с новым сервером или скорректировав DNS для сервера MySQL с отказавшего сервера на новый сервер.

Для получения дополнительной информации и некоторых примеров решений см. Раздел 19.4.8, «Переключение источников во время отказа».

Проверьте значение системной переменной binlog_format:

mysql> SHOW VARIABLES LIKE 'binlog_format';

Показанное значение всегда одно из STATEMENT, ROW или MIXED. В режиме MIXED по умолчанию используется протоколирование на основе инструкций, но репликация автоматически переключается на протоколирование на основе строк в определённых условиях, таких как небезопасные инструкции. Дополнительную информацию о том, когда это может произойти, см. в Разделе 7.4.4.3, «Смешанный формат двоичного протоколирования».

Реплики автоматически узнают, какой формат использовать.

Запустите сервер с опцией --replicate-wild-ignore-table=mysql.%, чтобы игнорировать репликацию для таблиц в базе данных mysql.

Да.

Да.