|
Задавайте вопросы, мы ответим
Вы не зашли.
В MySQL InnoDB Cluster если нода была перезагружена, она не включается в кластер автоматически. Собственно, вопрос - а какое может быть логическое объяснение у такого поведения?
http://mysqlserverteam.com/mysql-innodb … e-cluster/
If mysqld restarts for any reason (crash, expected restart, reconfiguration etc), it will NOT be in the group anymore when it comes back up. It needs to rejoin it, which may have to be done manually in some cases. For that, you can use the cluster.rejoinInstance() command to bring it an instance back to the group. The parameter it takes is the URI of the instance.
Неактивен
Мне непонятны слова "manually in some cases". Анализировать логику разработчиков сложно пока у продукта нет полноценной документации. Скорее всего имеется в виду, что следить за состоянием кластера - отдельная работа, которая должна делаться внешними скриптами.
Неактивен
Судя по документации, они делают «так же, как в MongoDB». В монге нода не сможет присоединиться тогда, когда не сможет найти в кластере бинлогов со своего старого положения до текущего активного. Другое дело, что монга в этот момент сама перенальется, а тут, видимо, нет.
Ты не знаешь — они начали писать свой кластер, эта штука вообще с галерой никак не связана?
Неактивен
Последние 5 статей на mysqlserverteam.com как раз и посвящены новому кластеру.
Но некоторые моменты реализации вызывают недоумение, например, оставшаяся в меньшинстве часть не выполняет изменения, но продолжает отвечать на read-only запросы. Это ведь может привести к рассогласованию между приложением и базой данных. Например, если кластер разделился на 2 части: большую, которая продолжает выполнять обновления, и меньшую, из которой можно только читать, а приложение будет попеременно обращаться к разным частям.
Неактивен
Есть такая штука, которая называется CAP-теорема. В современном мире популярно делать AP-системы и называть это «eventually consistent».
Неактивен
