Баг «плавающий», но можете попробовать. Всю необходимую информацию о конфигурации можем предоставить.
Обсуждение данной проблемы и ответ разработчика orchestrator на github.com/openark/orchestrator/issues/1132
Правильно ли я понял, что во время failover у вас кластер из 3 нод развалился на 3 отдельных нереплицирующихся узла?
Да, но проблема не в этом. Это не просто 3 отдельных нереплицирующихся узла, а в понимании оркестратора 3 отдельных кластера у каждого по 1 нереплицирующемуся узлу.
У каждого из этих кластеров есть свои ClusterName и ClusterAlias:
1) Старый мастер, ClusterName = 10.0.0.31:3306, ClusterAlias = 10.0.0.31:3306
2) Новый мастер, ClusterName = 10.0.0.32:3306, ClusterAlias = testcluster
3) Реплика, которая не смогла подключиться, ClusterName = 10.0.0.33:3306, ClusterAlias = 10.0.0.33:3306
При такой схеме если мы попросим оркестратора отдать адрес мастера testcluster, он вернет 10.0.0.32:3306 и это врено.
Проблема заключается в том, что Оркестратор через некоторое время простоя без каких либо причин присвоил ClusterAlias = testcluster кластеру с репликой, то есть другому кластеру.
После этого картина изменилась следующим образом:
1) Старый мастер, ClusterName = 10.0.0.31:3306, ClusterAlias = 10.0.0.31:3306
2) Новый мастер, ClusterName = 10.0.0.32:3306, ClusterAlias = 10.0.0.32:3306
3) Реплика, которая не смогла подключиться, ClusterName = 10.0.0.33:3306, ClusterAlias = testcluster
А при такой схеме если мы попросим оркестратора отдать адрес мастера testcluster, он вернет 10.0.0.33:3306 и это ошибка!
И это не противоречит его логике.
Понятное дело, что 1 кластер развалился на 3 отдельных и требуется вмешательство администратора. Но реакция администратора может занять определенное время, за которое оркестратор уже создал проблему.
Зависит ли Ваша система от связи ClusterAlias и IP адреса, который хранится под этим ClusterAlias у оркестратора?
Скажите, пожалуйста, не сталкивались ли Вы с такой ситуацией, когда Orchestrator присваивал ClusterAlias произвольным хостам, которые были вынесены в отдельные кластеры в процессе FailoverProcesses?
До шардирования пока ещё далеко, но вот при выборе кластера, к примеру, Vitess может быть заменителем Percona XtraDB Cluster или только работать поверх него (обслуживать запросы)?
Ну можно же полноценно использовать Vitess без оркестратора? Или отказоустойчивость штатными средствами Vitess будет недостаточно?
Я ещё не до конца дочитал документацию по Vitess, но раз уж вы его используете, то такой вопрос:
Умеет ли vitess.io без Orchestrator автоматически сделать слейв мастером в случае сбоя мастера?
Обсуждение данной проблемы и ответ разработчика orchestrator на github.com/openark/orchestrator/issues/1132
Да, но проблема не в этом. Это не просто 3 отдельных нереплицирующихся узла, а в понимании оркестратора 3 отдельных кластера у каждого по 1 нереплицирующемуся узлу.
У каждого из этих кластеров есть свои ClusterName и ClusterAlias:
1) Старый мастер, ClusterName = 10.0.0.31:3306, ClusterAlias = 10.0.0.31:3306
2) Новый мастер, ClusterName = 10.0.0.32:3306, ClusterAlias = testcluster
3) Реплика, которая не смогла подключиться, ClusterName = 10.0.0.33:3306, ClusterAlias = 10.0.0.33:3306
При такой схеме если мы попросим оркестратора отдать адрес мастера testcluster, он вернет 10.0.0.32:3306 и это врено.
Проблема заключается в том, что Оркестратор через некоторое время простоя без каких либо причин присвоил ClusterAlias = testcluster кластеру с репликой, то есть другому кластеру.
После этого картина изменилась следующим образом:
1) Старый мастер, ClusterName = 10.0.0.31:3306, ClusterAlias = 10.0.0.31:3306
2) Новый мастер, ClusterName = 10.0.0.32:3306, ClusterAlias = 10.0.0.32:3306
3) Реплика, которая не смогла подключиться, ClusterName = 10.0.0.33:3306, ClusterAlias = testcluster
А при такой схеме если мы попросим оркестратора отдать адрес мастера testcluster, он вернет 10.0.0.33:3306 и это ошибка!
И это не противоречит его логике.
Понятное дело, что 1 кластер развалился на 3 отдельных и требуется вмешательство администратора. Но реакция администратора может занять определенное время, за которое оркестратор уже создал проблему.
Зависит ли Ваша система от связи ClusterAlias и IP адреса, который хранится под этим ClusterAlias у оркестратора?
Я вижу, что здесь Вы указываете Orchestrator-у считывать ClusterAlias из БД.
Значит существует таблица cluster в базе meta, которая реплицируется на другие хосты. В этой таблице хранится ClusterAlias одинаковый для всех хостов.
Вот здесь у Вас используется ClusterAlias.
Скажите, пожалуйста, не сталкивались ли Вы с такой ситуацией, когда Orchestrator присваивал ClusterAlias произвольным хостам, которые были вынесены в отдельные кластеры в процессе FailoverProcesses?
Что можете посоветовать в вот такой ситуации?
github.com/openark/orchestrator/issues/1132
Я ещё не до конца дочитал документацию по Vitess, но раз уж вы его используете, то такой вопрос:
Умеет ли vitess.io без Orchestrator автоматически сделать слейв мастером в случае сбоя мастера?