20.1.3.1 Режим с одним первичным сервером
В режиме с одним первичным сервером (group_replication_single_primary_mode=ON) группа содержит один первичный сервер, работающий в режиме чтения/записи. Все остальные члены группы работают в режиме только чтения (с super_read_only=ON). Первичный сервер обычно инициализирует всю группу. Все остальные серверы, присоединяющиеся к группе, узнают о первичном сервере и автоматически переходят в режим только чтения.
В режиме с одним первичным сервером Group Replication гарантирует, что только один сервер выполняет запись в группу. По сравнению с режимом с несколькими первичными серверами, проверка согласованности может быть менее строгой, а операторы DDL не требуют особого обращения. Параметр group_replication_enforce_update_everywhere_checks включает или отключает строгую проверку согласованности для группы. При развертывании в режиме с одним первичным сервером или при изменении режима группы на режим с одним первичным сервером этот системный параметр должен быть установлен на OFF.
Член, назначенный первичным сервером, может измениться следующим образом:
Если существующий первичный сервер покидает группу добровольно или неожиданно, новый первичный сервер выбирается автоматически.
Вы можете назначить конкретного члена новым первичным сервером, используя функцию
group_replication_set_as_primary().Если вы используете функцию
group_replication_switch_to_single_primary_mode()для переключения группы, работающей в режиме с несколькими первичными серверами, на режим с одним первичным сервером, новый первичный сервер выбирается автоматически, или вы можете назначить новый первичный сервер, указав его в функции.
При выборе нового первичного сервера (автоматически или вручную) он автоматически переходит в режим чтения/записи, а другие члены группы остаются вторичными и, следовательно, работают в режиме только чтения. На диаграмме показан этот процесс:
Рисунок 20.4 Выбор нового первичного сервера
Когда выбирается новый первичный сервер, у него могут быть накопленные изменения, которые были применены на старом первичном сервере, но еще не применены на новом. В этом случае до тех пор, пока новый первичный сервер не догонит старый, транзакции чтения/записи могут привести к конфликтам и быть отменены, а транзакции только чтения могут привести к устаревшим данным. Механизм управления потоком Group Replication минимизирует разницу между быстрыми и медленными членами, и тем самым снижает вероятность этого, если он активирован и правильно настроен. Дополнительная информация приведена в разделе 20.7.2, «Управление потоком». Вы также можете использовать системную переменную group_replication_consistency для установки уровня согласованности транзакций группы для предотвращения этой проблемы. Установка этого параметра на BEFORE_ON_PRIMARY_FAILOVER (по умолчанию) или на любой более высокий уровень согласованности удерживает новые транзакции на вновь избранном первичном сервере до тех пор, пока не будет обработана задержка.
Дополнительная информация о согласованности транзакций приведена в разделе 20.5.3, «Гарантии согласованности транзакций». Если управление потоком и гарантии согласованности транзакций не используются для группы, рекомендуется подождать, пока новый первичный сервер применит журнал репликации прежде, чем перенаправлять к нему клиентские приложения.
20.1.3.1.1 Алгоритм выбора первичного сервера
Автоматический процесс выбора первичного члена включает в себя проверку каждым членом нового состояния группы, упорядочение потенциальных новых первичных членов и выбор члена, который считается наиболее подходящим. Каждый член принимает собственное решение локально, следуя алгоритму выбора первичного сервера в своей версии MySQL Server. Поскольку все члены должны прийти к одному решению, члены адаптируют свой алгоритм выбора первичного сервера, если другие члены группы используют более старые версии MySQL Server, чтобы их поведение соответствовало поведению члена с самой старой версией MySQL Server в группе.
Факторы, которые учитываются членами при выборе первичного сервера, в порядке приоритета, следующие:
Первым фактором является определение члена или членов, использующих самую старую версию MySQL Server. Все члены группы сначала упорядочиваются по номеру патча своей версии.
-
Если более чем один член использует самую старую версию MySQL Server, вторым фактором является вес каждого из этих членов, как указано в системной переменной
group_replication_member_weightна члене.Системная переменная
group_replication_member_weightзадаёт число в диапазоне от 0 до 100. Все члены по умолчанию имеют вес 50, поэтому установление веса ниже этого значения понижает их порядок, а выше - повышает. Вы можете использовать это взвешивание для приоритезации использования лучшего оборудования или для обеспечения отказоустойчивости к определённому члену при плановом обслуживании первичного сервера. Если более чем один член использует самую старую версию MySQL Server и более чем один из этих членов имеет наивысший вес (или весовой фактор игнорируется), третьим фактором является лексикографический порядок сгенерированных UUID серверов каждого члена, как указано в системной переменной
server_uuid. Член с самым низким UUID сервера выбирается в качестве первичного. Этот фактор служит гарантированным и предсказуемым развязывающим условием, чтобы все члены группы пришли к одному решению, если это невозможно определить по важным факторам.
20.1.3.1.2 Поиск первичного сервера
Для определения сервера, являющегося в данный момент первичным при развертывании в режиме с одним первичным сервером, используйте столбец MEMBER_ROLE в таблице performance_schema.replication_group_members. Например:
mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------------------+-------------+
| MEMBER_HOST | MEMBER_ROLE |
+-------------------------+-------------+
| remote1.example.com | PRIMARY |
| remote2.example.com | SECONDARY |
| remote3.example.com | SECONDARY |
+-------------------------+-------------+
© 2025 Oracle
Licensed under the GPLv2 License.
