Лучше 4 сервера в кластере, но если нужно сократить число серверов к минимуму и экономить их мощность. То можно использовать слабый сервер, как арбиттратор.
innodb_flush_log_at_trx_commit=0 это перебор как мне кажется. innodb_locks_unsafe_for_binlog устарел уже в 5.6/10, но почему лучше в 0? что бы избежать фантомного чтения?
Я выше ответил про cluster-wide deadlocks,
так же там в параметрах есть тот, который отвечает за ретраи дедлока. Проблема решается при использовании maxscale.
в заготовках для всех конфинах меняется только адрес ноды, имя ноды и список существущих нод. Текущая всегда будет последней в списке wsrep_urls
Инициировать кластер пустой gcomm:// до сих пор нужно)
никакого гемороя не будет. Важно понимать что, 2 ноды это мало. нужно как минимум 2 и абраттратор. А лучше 3 или 4.
Записывать нужно в один сервер или по крайней мере, что бы набор баз и таблиц в которую ведется запись была разной.
MaxScale умеет отправлять запись в один набор нод а чтение в другой. Причем на уровне запросов а не соединений.
не сложно. Все происходит автоматически при запуске выпавшей ноды. Иногда нужно удалить все ее локальные данные и перезагрузить еще раз.
Различают 2 варианта передачи состояний. Полное и инкрементальное. При повреждении локальных данных или первом старте, будет происходить полный SST.
По балансировке — HAProxy или MaxScale. По первому, ссылка на статью в начале текста.
сохранность данных на диске конкретоной ноды, это не очень важный фактор. состояние будет передано при sst. а вот для ускорения работы кластера в целом, нужно минимизировать работу субд с диском до минимально необходимого
Нужно держать разные участки кластера в разных gmcast.segment, тогда что то еще получится.
Подробнее стоит почитать о gmcast.segment в документации по galera 3
Если не согласовать кеш то прочитав данные из другой ноды ты получишь уже не актуальные на данный момент.
Возможен любой вариант, это полноценный синхронный мульти-мастер. Во все ноды можно писать и читать одновременно.
в query_cache хранятся хеши запросов и ответы на них, в innodb копии страниц данных, с диска.
Те в одном случае результат в другом — исходные данные.
innodb должен быть как можно больше, так что бы вместить данные базы и не ходить за ними на диск.
query_cache должен быть минимально необходимым, до 512МБ максимум.
Нет его отключают совершенно по другой причине. Его не внедряли ранее, так как очень трудно согласовать кеш между всеми нодами и на первых порах это приводило к дедлоку по причине кеша. Те на одной ноде поменялась запись и значит кеш должен сбросится на всех. А допустим где то сервер под нагрузкой и кеш не сбрасывается и в итоге все ноды ждут сброса кеша на одной из нод. В итоге они напряглись и починили это. Теперь работает как часы, главное выполнять рекомендации.
innodb
не будет коммита, если не будет коммита на всех нодах кворума. Так что ничего не сможет вставится при потере связанности. Нода без кворума переходит в точно для чтения или вообще закрывается.
просто удаляешь оба инстанса и ставишь галеру. плюс арбиттратор.
ну и mysql_upgrade --force
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.74,192.168.0.75,192.168.0.76
вторая, ее адрес 192.168.0.75
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.74,192.168.0.76,192.168.0.75
третья, ее адрес 192.168.0.74
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.76,192.168.0.75,192.168.0.74
итд
что у вас за мульти-мастер?
так же там в параметрах есть тот, который отвечает за ретраи дедлока. Проблема решается при использовании maxscale.
в заготовках для всех конфинах меняется только адрес ноды, имя ноды и список существущих нод. Текущая всегда будет последней в списке wsrep_urls
Инициировать кластер пустой gcomm:// до сих пор нужно)
Записывать нужно в один сервер или по крайней мере, что бы набор баз и таблиц в которую ведется запись была разной.
MaxScale умеет отправлять запись в один набор нод а чтение в другой. Причем на уровне запросов а не соединений.
Различают 2 варианта передачи состояний. Полное и инкрементальное. При повреждении локальных данных или первом старте, будет происходить полный SST.
По балансировке — HAProxy или MaxScale. По первому, ссылка на статью в начале текста.
Документация: cloud.sycraft.info/index.php/s/ff1d36ddb40239262f276d2cd0478196
Описание: www.opennet.ru/opennews/art.shtml?num=41475
но можно и haproxy.
Подробнее стоит почитать о gmcast.segment в документации по galera 3
Возможен любой вариант, это полноценный синхронный мульти-мастер. Во все ноды можно писать и читать одновременно.
в query_cache хранятся хеши запросов и ответы на них, в innodb копии страниц данных, с диска.
Те в одном случае результат в другом — исходные данные.
innodb должен быть как можно больше, так что бы вместить данные базы и не ходить за ними на диск.
query_cache должен быть минимально необходимым, до 512МБ максимум.
innodb