20.1.4.2 Обнаружение неполадок
Механизм обнаружения неполадок Group Replication представляет собой распределенную службу, способную определить, что сервер в группе не взаимодействует с другими, и, следовательно, считается недоступным. Если консенсус группы таков, что подозрение, вероятно, истинно, группа принимает скоординированное решение об исключении участника. Исключения участника, не взаимодействующего с группой, необходимо, поскольку группе требуется большинство ее членов для согласования транзакции или изменения состояния. Если участник не участвует в этих решениях, группа должна его удалить, чтобы повысить вероятность того, что группа содержит большинство исправно работающих участников и, следовательно, может продолжить обработку транзакций.
В группе репликации каждый участник имеет двусторонний канал связи с каждым другим участником, образуя полностью связный граф. Эти соединения управляются движком групповой коммуникации (XCom, вариант Paxos) и используют сокеты TCP/IP. Один канал используется для отправки сообщений участнику, а другой — для получения сообщений от участника. Если участник не получает сообщений от другого участника в течение 5 секунд, он предполагает, что участник вышел из строя, и записывает состояние этого участника как UNREACHABLE в своей собственной таблице Performance Schema replication_group_members. Обычно два участника будут подозревать друг друга в выходе из строя, потому что каждый из них не взаимодействует с другим. Хотя менее вероятно, что участник A подозревает участника B в выходе из строя, но участник B не подозревает участника A в выходе из строя — возможно, из-за проблемы с маршрутизацией или брандмауэром. Участник также может создать подозрение о себе. Участник, изолированный от остальной части группы, предполагает, что все остальные вышли из строя.
Если подозрение сохраняется более 10 секунд, подозревающий участник пытается распространить свое мнение о том, что подозреваемый участник неисправен, на других участников группы. Подозревающий участник делает это только в том случае, если он является нотификатором, рассчитанным по его внутреннему номеру узла XCom. Если участник фактически изолирован от остальной части группы, он может попытаться распространить свое мнение, но это не будет иметь последствий, поскольку он не может обеспечить кворум других участников для согласия с ним. Подозрение имеет последствия только в том случае, если участник является нотификатором, и его подозрение сохраняется достаточно долго, чтобы его распространить на других участников группы, и другие участники соглашаются с ним. В этом случае подозреваемый участник отмечается для исключения из группы в скоординированном решении и исключается после истечения периода ожидания, установленного системной переменной group_replication_member_expel_timeout, и механизм исключения обнаруживает и выполняет исключение.
Если сеть нестабильна, и участники часто теряют и восстанавливают соединение друг с другом в разных комбинациях, теоретически возможно, что группа в конечном итоге отметит всех своих участников для исключения, после чего группа перестанет существовать и должна быть настроена заново. Чтобы противостоять этой возможности, система групповой коммуникации Group Replication (GCS) отслеживает участников группы, которые были помечены для исключения, и рассматривает их так, как если бы они находились в группе подозреваемых участников при принятии решения о том, существует ли большинство. Это гарантирует, что по крайней мере один участник остается в группе, и группа может продолжить свое существование. Когда исключенный участник фактически удален из группы, GCS удаляет запись об отметке участника для исключения, чтобы участник мог присоединиться к группе, если это возможно.
Сведения о системных переменных Group Replication, которые можно настроить для указания реакций работающих участников группы на ситуации с неполадками и действий участников группы, которых подозревают в неполадках, см. в Разделе 20.7.7 «Реакции на обнаружение неполадок и разделение сети».
© 2025 Oracle
Licensed under the GPLv2 License.