8.10.2 Inconsistent Transaction Sets (GTID Sets) in InnoDB ClusterSet Clusters — MySQL Shell 8.4

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

Команда AdminAPI's clusterSet.status() предупреждает вас, если набор GTID кластера InnoDB не согласован с набором 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. Подробности об этой операции см. в разделе 7.8.1, «Присоединение экземпляра к кластеру».

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

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

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