9.10.2 Inconsistent Transaction Sets (GTID Sets) in InnoDB ClusterSet Clusters — MySQL Shell 9.2

9.10.2 Несовместимые наборы транзакций (наборы GTID) в кластерах InnoDB ClusterSet

Команда AdminAPI's clusterSet.status() предупреждает вас, если набор GTID InnoDB Cluster несовместим с набором GTID первичного кластера в InnoDB ClusterSet. Кластер в этом состоянии имеет дополнительные транзакции по сравнению с другими кластерами в InnoDB ClusterSet и имеет глобальный статус OK_NOT_CONSISTENT. Кластер продолжает функционировать в InnoDB ClusterSet с этим статусом, и вы можете выполнить аварийный failover к нему, если его набор GTID является самым обновлённым среди доступных реплицирующих кластеров. Однако он не подходит для плавного переключения, так как разница в транзакциях может привести к тому, что клиенты получат некорректные данные. Кластер также не может присоединиться обратно к InnoDB ClusterSet с дополнительными транзакциями, если он отключится.

Реплицирующий кластер в InnoDB ClusterSet является только для чтения, поэтому, если он всегда был реплицирующим кластером, он не должен содержать дополнительных транзакций, если изменения не были внесены в кластер без использования команд AdminAPI. Если вам необходимо выполнить административные транзакции на экземпляре во время остановки Group Replication, всегда установите значение системной переменной sql_log_bin в значение OFF перед выполнением административных операторов и верните его к значению ON после этого:

SET SQL_LOG_BIN=0;
<administrator action>
SET SQL_LOG_BIN=1;

Установка этой системной переменной в значение OFF означает, что транзакции, происходящие с этого момента до момента её возврата к значению ON, не записываются в двоичный журнал и не имеют назначенных им GTID.

Ситуация, которая может создать разошедшийся набор транзакций без внешних изменений, возникает, когда первичный кластер становится недоступным и используется процедура аварийного failover. Если первичный кластер остаётся онлайн после failover, он может продолжать принимать транзакции от клиентов через любые экземпляры MySQL Router, которые всё ещё подключены к нему, и передавать их любым реплицирующим кластерам, которые всё ещё подключены к нему. В качестве альтернативы, существенная задержка репликации может привести к тому, что реплицирующий кластер, выбранный в качестве заменяющего первичного кластера, пропустит некоторые транзакции из первичного кластера. В этом случае, когда старый первичный кластер первоначально снова становится онлайн как невалидированный реплицирующий кластер, транзакции, которые никогда не были переданы реплике, распознаются как дополнительные транзакции.

Расширенный вывод команды clusterSet.status() определяет любые кластеры, которые имеют дополнительные транзакции, и присваивает им глобальный статус OK_NOT_CONSISTENT. Например:

mysql-js> myclusterset.status({extended: 1})
{
    "clusters": {
        "clusterone": {
            "clusterErrors": [
                "ERROR: Errant transactions detected"
            ],
            "clusterRole": "REPLICA",
            "clusterSetReplication": {
                "applierStatus": "APPLIED_ALL",
                "applierThreadState": "Waiting for an event from Coordinator",
                "applierWorkerThreads": 4,
                "receiver": "127.0.0.1:3310",
                "receiverStatus": "ON",
                "receiverThreadState": "Waiting for source to send event",
                "source": "127.0.0.1:4410"
            },
            "clusterSetReplicationStatus": "OK",
            "globalStatus": "OK_NOT_CONSISTENT",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:3310": {
                    "address": "127.0.0.1:3310",
                    "memberRole": "PRIMARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3320": {
                    "address": "127.0.0.1:3320",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3330": {
                    "address": "127.0.0.1:3330",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "54ff337b-2ccf-11ec-95da-3c6aa7197deb:1-131,54ff3ed7-2ccf-11ec-95da-3c6aa7197deb:1-5,c06527d6-2ce3-11ec-a55e-3c6aa7197deb:1,c0653492-2ce3-11ec-a55e-3c6aa7197deb:1-5",
            "transactionSetConsistencyStatus": "INCONSISTENT",
            "transactionSetConsistencyStatusText": "There are 1 transactions that were executed in this instance that did not originate from the PRIMARY.",
            "transactionSetErrantGtidSet": "c06527d6-2ce3-11ec-a55e-3c6aa7197deb:1",
            "transactionSetMissingGtidSet": ""
        },
        "clustertwo": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:4410",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:4410": {
                    "address": "127.0.0.1:4410",
                    "memberRole": "PRIMARY",
                    "mode": "R/W",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4420": {
                    "address": "127.0.0.1:4420",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4430": {
                    "address": "127.0.0.1:4430",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "54ff337b-2ccf-11ec-95da-3c6aa7197deb:1-131,54ff3ed7-2ccf-11ec-95da-3c6aa7197deb:1-5"
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:4410",
    "metadataServer": "127.0.0.1:4410",
    "primaryCluster": "clustertwo",
    "status": "AVAILABLE",
    "statusText": "Primary Cluster available, there are issues with a Replica cluster."
}

Наиболее безопасный метод согласования данных отдельного сервера со всем остальным InnoDB Cluster состоит в том, чтобы определить сервер в развертывании InnoDB ClusterSet, который имеет наилучшие данные (наибольшее количество транзакций, самые последние транзакции или самые важные транзакции), и использовать функциональность клонирования MySQL для передачи содержимого с этого сервера на затронутый сервер. Инструкции по выполнению этой задачи см. в . Затем используйте команду cluster.rejoinInstance(), чтобы экземпляр присоединился обратно к InnoDB Cluster. Подробности этой операции см. в разделе 8.8.1, «Присоединение экземпляра к кластеру».

Если затронут весь InnoDB Cluster, удалите затронутый кластер из развертывания InnoDB ClusterSet, следуя процедуре в разделе 9.10.4, «Удаление кластера из InnoDB ClusterSet», и создайте новый InnoDB Cluster на его месте. Экземпляры серверов в новом InnoDB Cluster получат правильный набор транзакций в ходе процесса настройки.

Если вы хотите сохранить дополнительные транзакции, можно выполнить аварийный failover, чтобы сделать InnoDB Cluster с этими транзакциями первичным кластером, следуя процедуре в разделе 9.9, «Аварийный failover InnoDB ClusterSet».

Если вы можете справиться с проблемами транзакций, используйте операцию clusterSet.rejoinCluster() для повторного присоединения InnoDB Cluster к развертыванию InnoDB ClusterSet. Инструкции по этому см. в разделе 9.10.5, «Повторное присоединение кластера к InnoDB ClusterSet».