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

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

Да, сетевое подключение должно быть включено на источнике и реплике. Если сетевое подключение отключено, реплика не сможет подключиться к источнику и перенести бинарный лог. Убедитесь, что системная переменная 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 выполняет обновление на копии 1, а в это время, прежде чем оно распространится на копию 2, клиент B выполняет обновление на копии 2, что приводит к тому, что обновление клиента A будет работать иначе, чем на копии 1. Таким образом, когда обновление клиента A доходит до копии 2, оно создаёт таблицы, отличающиеся от тех, что есть на копии 1, даже после распространения всех обновлений с копии 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.

Да.

Да.