Spec-Zone .ru
спецификации, руководства, описания, API

B.13. FAQ MySQL 5.7: Репликация

В следующем разделе мы обеспечиваем ответы на вопросы, которые наиболее часто спрашивают о MySQL Replication.

Вопросы

Вопросы и Ответы

B.13.1: ведомое устройство должно быть соединено с ведущим устройством все время?

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

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

B.13.2: я должен позволить объединиться в сеть на моем ведущем устройстве и ведомом устройстве, чтобы включить репликации?

Да, сети должны быть включены на ведущем устройстве и ведомом устройстве. Если сети не включаются, ведомое устройство не может соединиться с ведущим устройством и передать двоичный журнал. Проверьте что skip-networking опция не была включена в конфигурационном файле ни для одного сервера.

B.13.3: Как я знаю, как поздно ведомое устройство по сравнению с ведущим устройством? Другими словами, как я знаю дату последнего оператора, тиражированного ведомым устройством?

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

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

B.13.4: Как я вынуждаю ведущее устройство блокировать обновления, пока ведомое устройство не нагоняет?

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

  1. На ведущем устройстве выполните эти операторы: 

    mysql> FLUSH TABLES WITH READ
                    LOCK;mysql> SHOW MASTER
                    STATUS;

    Запишите координаты репликации (текущее двоичное имя файла журнала и позиция) от вывода SHOW оператор.

  2. На ведомом устройстве сделайте следующее заявление, где параметры MASTER_POS_WAIT() функция является значениями координаты репликации, полученными в предыдущем шаге: 

    mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);

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

  3. На ведущем устройстве сделайте следующее заявление, чтобы позволить ведущему устройству начать обрабатывать обновления снова: 

    mysql> UNLOCK
                    TABLES;

B.13.5: О каких проблемах я должен знать, устанавливая двухстороннюю репликацию?

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

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

B.13.6: Как я могу использовать репликацию, чтобы улучшить производительность моей системы?

Установите один сервер как ведущее устройство и прямой все записи к этому. Затем сконфигурируйте так много ведомых устройств, как Вы имеете бюджет и rackspace для, и распределяете чтения среди ведущего устройства и ведомых устройств. Можно также запустить ведомые устройства с --skip-innodb, --low-priority-updates, и --delay-key-write=ALL опции, чтобы получить улучшения скорости на ведомом конце. В этом случае, ведомое нетранзакционное использование MyISAM таблицы вместо InnoDB таблицы, чтобы получить больше скорости, устраняя транзакционные издержки.

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

См. руководство по использованию репликации как решение масштаба, Раздел 16.3.3, "Используя Репликацию для Масштаба".

B.13.8: Когда и насколько репликация MySQL может улучшить производительность моей системы?

Репликация MySQL является самой выгодной для системы, которая обрабатывает частые чтения и нечастые записи. В теории, при использовании установки single-master/multiple-slave, невозможно масштабировать систему, добавляя больше ведомых устройств до Вас или исчерпанный сетевая пропускная способность, или Ваша загрузка обновления растет до такой степени, что ведущее устройство не может обработать это.

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

Скажем, та системная нагрузка состоит из 10%-ых записей и 90%-ых чтений, и мы определили, тестируя этого в сравнении с эталоном reads 1200 - 2 * writes. Другими словами система может сделать 1 200 чтений в секунду без записей, средняя запись является дважды столь же медленной как среднее чтение, и отношение линейно. Предположите, что у ведущего устройства и каждого ведомого устройства есть та же самая емкость, и что у нас есть одно ведущее устройство и N ведомые устройства. Затем мы имеем для каждого сервера (ведущее устройство или ведомое устройство):

reads = 1200 - 2 * writes

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

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

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

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

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

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

B.13.9: Как я могу использовать репликацию, чтобы обеспечить избыточность или высокую доступность?

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

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

Для получения дополнительной информации и некоторые решения в качестве примера, см. Раздел 16.3.6, "Переключая Ведущие устройства Во время Failover".

B.13.10: Как я говорю, использует ли главный сервер основанный на операторе или основанный на строке двоичный формат журналирования?

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

mysql> SHOW VARIABLES LIKE
        'binlog_format';

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

B.13.11: Как я говорю ведомому устройству использовать построчную репликацию?

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

B.13.12: Как делают я предотвращаю GRANT и REVOKE операторы с тиражирования на ведомые машины?

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

B.13.13: репликация работает над смешанными операционными системами (например, ведущее устройство работает на Linux в то время как ведомые устройства, на которых работают Mac OS X и Windows)?

Да.

B.13.14: репликация работает над смешанной аппаратной архитектурой (например, ведущее устройство работает на 64-разрядной машине в то время как ведомые устройства, на которых работают 32-разрядные машины)?

Да.

Авторское право © 1997, 2013, Oracle и/или его филиалы. Все права защищены. Официальные уведомления
Домой