Вопросы помечу жирным курсивом. Ответы будут обычным текстом.
Света, Добрый день. По вашему мнению какая схема работы Percona XtraDB Cluster наиболее предпочтительная? Возможно ли в качестве фронтенда для кластера добавить балансировщик нагрузки (HAProxy)? Каким образом организовать бекап БД? Какое "железо" исходя из практики наиболее предпочтительнее? Какие подводные камни могут быть исходя из предложенных исходных данных? Исходные данные: 1) Есть 3 дата-центра, между которым организован хороший канал передачи данных (3 ноды mysql сервера в каждая отдельном ДЦ). 2) База данных размером 90ГБ. 3) 7000 одновременных (конкурентных) запросов в БД.
В трёх дата-центрах (ДЦ) однозначно не нужно. Дело в том, что Percona XtraDB Cluster (PXC) синхронный. Это значит, что COMMIT не завершится, пока не получит подтверждение от всех нод, что изменения дошли. То есть нода в одном ДЦ будет ждать ответа от двух других. Это обычно достаточно долго. Если вы всё-таки решите делать такое решение, увеличьте переменные, отвечающие за ожидаемый delay между нодами (см. полный список здесь). В противном случае кластер будет регулярно "терять" то одну, то другую ноду и приходить в нерабочее состояние.
PXC обычно используют для масштабирования чтения и синхронизации записи, если необходимо писать на всех нодах. Обычно, если ноды используются в различных ДЦ, логика как-то разделяется. Например, по географическому признаку. В этом случае можно и нужно использовать обычную асинхронную репликацию. При этом можно настроить асинхронную репликацию между тремя кластерами, установленными в каждом датацентре.
HAProxy использовать не только можно, но и нужно. Это рекомендуемое классическое решения для балансировки нагрузки.
По железу рекомендации обычные: быстрый диск, память должна вмещать активный набор данных. Кстати, у вас сравнительно небольшой объём данных и вы можете поместить его полностью в память (в InnoDB Buffer Pool) и сильно сэкономить на скорости диска.
За конкурентные запросы отвечает CPU. Чем больше ядер, тем больше кокурентных запросов вы сможете обработать. Но тут нужно отличать количество запросов, которые посылает приложение, и количество запросов, обрабатываемых внутри InnoDB: последнее обычно меньше даже при большой нагрузке за счёт того, что часть соединений находится в спящем режиме пока приложение получает или обрабатывает данные.
Если у вас реально 7000 активных соединений, имеет смысл присмотреться к Thread Pool Plugin
Когда будет исправлен баг https://bugs.mysql.com/bug.php?id=11472 ? И почему его так долго не исправляют?
Этот вопрос нужно задать менеджерам и разработчикам Oracle. Но я подозреваю, что требуется согласование работы между InnoDB и Runtime. Дело в том, что за внешние ключи отвечает движок (InnoDB), а за исполнение триггеров - Runtime. И, чтобы исправить этот баг, по уму нужно реализовать несколько коммуникаций между движком и Runtime. Для одного InnoDB это, возможно, сделать проще. Но MySQL поддерживает несколько движков и правильно делать именно через абстрактный интерфейс. Я думаю, что баг будет исправлен, когда появятся внешние ключи на уровне сервера. В версии 8.0 есть подвижки в этом направлении. Хотя, насколько я могу судить, до исправления именно данного бага ещё очень далеко.
Я слышал такое мнение, что MySQL является очень надежной БД. Даже при настройке репликации она не завершит запрос, пока не дождется ответа от всех остальных серверов. А остальные СУБД имеют более слабые гарантии и за счет этого кичатся своим быстродействием. Правда ли это?Правда ли что MySQL очень надежна?И правда ли что остальные СУБД быстрее только за счет того нарушают какие-либо гарантии?
Такое впечатление, что вы говорите о PXC, на вопрос про который я отвечала в начале поста. Это отдельный продукт. Также как и Galera, и новая фича MySQL Group Replication.
Репликация же по умолчанию в MySQL асинхронная. И в случае асинхронной репликации мастер ничьих ответов ждать не будет. Я делала презентацию для Highload++ в этом году про отладку репликации MySQL. Там есть несколько слайдов именно про то, какая бывает репликация, надёжное ли такое решение или быстрое.
Насчёт других СУБД: я бы не сказала, что там репликация решена ненадёжно. Просто нужно хорошо понимать особенности того или иного решения.
Какие инструменты Вы можете посоветовать для отладки запросов к MySQL. Как понять что надо исправить, чтобы запрос стал быстрее? Надо ли добавить ключ или полностью переписать запрос?
Нужно использовать EXPLAIN для понимания того, как планируется выполнение запроса; статистику движка и таблицу INFORMATION_SCHEMA.OPTIMIZER_TRACE, чтобы узнать, что именно происходило во время выполнения; и просматривать статистику таблицы.
По поводу добавления ключа или модификации запроса общего ответа нет: каждый случай решается в индивидуальном порядке.
Я делала вебинар на английском языке на эту тему. Запись и слайды можно посмотреть здесь.
Сильно ли тормозит нормализация структуры БД? И до какой степени стоит ее проводить?
Сама по себе нормализация не тормозит. Иногда могут требоваться сложные JOIN-ы между несколькими таблицами, которые по каким-то причинам не могут быть оптимизированы (JOIN-ы сами по себе тоже не тормозят). В таком случае имеет смысл денормализировать структуру. Однако нужно понимать, что в этом случае вы будете писать больше данных. Также появятся дополнительные блокировки, которые негативно скажутся на общем времени записи: там, где в нормилизированной структуре у вас будет уникальный ключ плюс блокировка одной строки, в денормализированной будет либо блокировка всей таблицы, либо нескольких строк.
Как и в других случаях, универсального ответа "где остановиться" не существует.
Как работают триггеры БД? И насколько целесообразно их использовать. Тормозят ли они работу БД? Есть ли какие-нибудь best practice для триггеров?
Сами по себе триггеры не тормозят. В MySQL триггеры вызываются для каждой изменяемой строки. Соответственно, если вы будете выполнять тяжёлую операцию в триггере, она будет выполняться для каждой изменяемой строки. То есть изменять 10,000 строк в какой-то таблице триггером не стоит. Касательно best practice: нужно помнить о блокировках. Например, если вы хотите в триггере на таблицу Foo обращаться к таблице Bar, следует писать команды таким образом, чтобы они не блокировали друг друга при конкурентных запросах к таблице Foo.
Здравствуйте, были ли в вашей практике проблемы, связанные с использованием многих databases в рамках одного сервера MySQL? Насколько хорошо MySQL работает, когда таких баз уже под 2000 и когда стоит начать думать о втором сервере?
Есть две проблемы.
Первая: лимиты операционной системы. Каждую базу MySQL хранит в отдельном каталоге. Соответственно, если таких каталогов много, файловой системе будет сложно с ними работать. Но там сильно большие числа нужны, 2000 проблем не вызовут.
Вторая: дизайн Information Schema до версии 8.0. При обращении к некоторым таблицам будет заметно подтормаживать из-за того, что в ней нет индексов. А так как большинство SHOW команд слинкованы с Information Schema, отладка будет затруднена. Также есть Java frameworks, которые злоупотребляют командами SHOW при создании соединений. Но тут, опять-таки, будет ещё зависеть от количества таблиц в базах. Если по 10 таблиц это будет full scan 20,000 "строк": не очень приятно, но ответа дождаться можно; если же их тоже по 2000, то 4,000,000, что намного хуже.