Juju MySQL добавление модулей против добавления нового сервиса с отношением

Какой смысл добавлять юниты в MySQL? Почему бы просто не создать новый сервис по отношению к главному узлу?

MySQL не поддерживает узел с несколькими хозяевами, поэтому добавление модулей в один сервис MySQL не имеет смысла. Если я создаю второй сервис в качестве подчиненного и добавляю к нему модули, которые будут действовать как несколько подчиненных, все равно не имеет смысла, потому что, если основной подчиненный сервер умирает, все присоединенные к нему объединения также становятся бесполезными.

Кто-нибудь может объяснить, почему я должен добавлять модули в MySQL?

4
задан 1 November 2013 в 01:39

1 ответ

Я попробую:

MySQL не поддерживает узел с несколькими хозяевами, поэтому добавление модулей в одну службу MySQL не имеет смысла.

То, что MySQL Community Server не поддерживает мультимастерный узел, является правильным. Для настройки многоузлового узла вам понадобится MySQL Cluster или вилка. Я также могу подтвердить, что на момент написания этого ответа не существовало очарования Джуджу для MySQL Cluster. Но MySQL Community Server поддерживает другие высокодоступные возможности для его репликации. Одним из наиболее очевидных из них является переключение мастеров при отказе.

Если вы ближе посмотрите на реализацию MySQL Charm , мы можем увидеть в hooks\ha* что-то, что я мог бы назвать переключением мастера. То есть я не погрузился так глубоко, что могу подтвердить, что это так.

Почему бы просто не создать новую службу по отношению к главному узлу?

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

, если основной подчиненный сервер умирает, все присоединенные к нему узлы также становятся бесполезными

Это не совсем верно, поскольку подчиненные серверы с радостью будут обслуживать запросы на чтение. Реплики MySQL также могут быть «вынуждены» обслуживать запросы на запись / обновление, но это категорически не рекомендуется, поскольку имеет серьезные сложности для сохранения семантики.

Согласно ответу на этот вопрос , Димитер Найденов, член Canonical Juju-core, добавляет больше юнитов в MySQL Charm, не создавая реплики рабов.

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

Этот проект, который вы могли бы найти интересным или вдохновляющим, мог бы стать этим .

Улучшения и исправления приветствуются.

0
ответ дан 1 November 2013 в 01:39
  • 1
    Я понимаю это you' ре, пытающееся сделать вещи легче, но понятие комментариев, довольно легко понять (' терминал игнорирует что-либо направо от хеша symbol' или что-то вдоль тех строк), и использующий ' hashtag' кажется, что это привело бы к большему количеству беспорядка если что-либо – evilsoup 1 May 2015 в 15:37

Другие вопросы по тегам:

Похожие вопросы: