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

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

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

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

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

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

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

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

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

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

Репликация 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 с отказавшего сервера на новый.

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

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

mysql> SHOW VARIABLES LIKE 'binlog_format';

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

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

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

Да.

Да.