Проектирование кластера XtraDB

Question

У нас есть приложение, которое состоит из микросервисов, подключенных к одному экземпляру Percona DB. В настоящее время это всего один экземпляр с 16 ядрами /32 ГБ памяти без репликации. Одна из наших проблем заключается в том, что иногда один из наших микросервисов вызывает такую ​​высокую нагрузку на базу данных (даже просто чтение), что делает все микросервисы непригодными для использования.

Мы думаем о создании кластера Percona из трех узлов с выбором узлов для каждого микросервиса. Службы, которые в основном "пишут", подключаются к одному экземпляру, а остальные подключаются к двум другим экземплярам. Таким образом, если какой-то микросервис вызывает высокую нагрузку на чтение, это не должно полностью перегружать нашу инфраструктуру.

Мои вопросы:

1. Это даже хорошая идея? Разве мы не должны позволить ProxySQL иметь дело с разделением трафика? ProxySQL будет означать отсутствие изоляции.
2. Должны ли мы иметь больше экземпляров с меньшим количеством процессоров или, скорее, меньше экземпляров с большим количеством процессоров? Наличие большего количества экземпляров будет означать большую изоляцию для запуска микросервисов в случае высокой нагрузки.
3. Хорошо ли иметь узлы с разными процессорами? Например, пусть "экземпляр записи" имеет больше ЦП по сравнению с "экземплярами чтения".
4. Если мы направим микросервисы на "их экземпляр Percona", можем ли мы по-прежнему иметь какую-то HA, когда их экземпляр полностью умирает?

Примечание. Вероятно, мы будем использовать Percona XtraDB для развертывания в GCE. https://console.cloud.google.com/marketplace/details/click-to-deploy-images/percona?project=goout-cloud&folder&organizationId=74390800864

Answer 1

1. Да, это хорошая идея. Использование ProxySQL с PXC также является хорошей идеей. Используя ProxySQL, вы можете: A) реализовать HA "писателя", поместив два узла в одну группу хостов, один с очень высоким весом (10000000), а другой с низким (10). Если большой узел переходит в автономный режим, ProxySQL без проблем начнет отправлять трафик на другой узел. B) поместите все узлы в отдельную группу хостов "считывателя" с одинаковыми весами, что позволит сбалансировать нагрузку при записи трафика. C) При желании создайте третью группу хостов всего с 1 узлом и создайте правило запроса для сопоставления с образцом в схеме, пользователе или шаблоне запроса для вашего запроса "высокой нагрузки" и прямого выполнения для этого конкретного узла. ProxySQL также позволит вам кэшировать некоторые из этих сложных запросов.

2. Лично я бы выбрал меньшее количество экземпляров с более высоким процессором, если вы не знаете, что ваша сеть надежна. В PXC все узлы должны синхронно подтверждать все транзакции. Чем больше у вас узлов, тем больше задержка может занять эти операции. Самое быстрое, что вы можете зафиксировать - это время между двумя самыми медленными узлами. Пожалуйста, убедитесь, что у вас всегда есть нечетное количество узлов, если вы не продвинулись с настройкой pc.weight (но это очень сложно сделать правильно).

3. С MySQL в целом все узлы должны быть одинаковой конфигурации. Если ваш хозяин более могущественен, чем рабы, вообще говоря, рабы не смогут идти в ногу с громкостью. С PXC это означает, что вы будете чаще сталкиваться с событиями управления потоком, что может привести к остановке приложений. Если узел2 не может записать как быстрый узел1, узел2 отправляет сообщения управления потоком (взывает о помощи), прося другие узлы замедлиться, пока он догоняет.

4. Да, используя ProxySQL, как описано в #1.

Дополнительное замечание: оптимизация запросов - это способ № 1 "ускорить процесс". Не всегда бросайте аппаратные средства на проблему. Стоит потратить время на изучение вашего медленного журнала запросов и попытаться улучшить запросы. Иногда один индекс может иметь значение ночь / день.

Отказ от ответственности: я являюсь старшим инструктором Percona и провёл множество интенсивных учебных занятий по PXC и ProxySQL в течение всего дня.

Answer 2

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

Добавление очереди только добавляет сложности и замедляет обработку, когда действия выполняются быстро. Так что "Не ставь в очередь, просто сделай это". Также обратите внимание, что очередь будет временно реплицироваться на другие узлы, что, следовательно, делает постановку в очередь / удаление очереди медленнее, чем просто действие по запросу!

Подключение - сделать что-то - отключение занимает много времени. Большую часть времени на самом деле не вовлечены в "что-то", а скорее накладные расходы вокруг него. Я считаю, что если активны менее 10 соединений, все идет гладко. Но если начинать более 10, InnoDB начинает спотыкаться.

Ты когда-нибудь был в переполненном магазине? Допустим, во всех проходах есть место для 200 человек и тележек. Но если вы попытаетесь привлечь 210 покупателей, все замедляются, просто пытаясь занять место. Пропускная способность снижается, возможно, до такой степени, что люди, желающие оставить свою тележку в отпуске. Когда-нибудь видели магазин с линией снаружи? Они решили проблему, не допустив более 200 покупателей одновременно!

Таким образом, решение вашей проблемы может быть за пределами MySQL. Если у вас есть веб-страница, выходящая на MySQL, ограничьте ее, чтобы ограничить количество используемых потоков. У Apache, например, есть такой плюс "отставание" для постановки в очередь на уровне подключения к Apache. MySQL есть max_connections а также backlog которые, возможно, работают так же, но по умолчанию для max_connections (151) слишком высоко. 151 студент, собравшийся возле автомата по продаже газировки в магазине, может быть лучшей аналогией.

Больше узлов / больше процессоров могут быть или не быть частью ответа; это зависит от того, какие замки вынесены "чем-то".

монитор Threads_running; если он увеличится до нескольких десятков, то я подозреваю, что мои комментарии применимы. Если программа монитора не может подключиться, проверьте это GLOBAL STATUSтогда я знаю, что это применимо.