Производительность репликации MySQL

Вау, у вас есть какое-то ужасное оборудование для этой проблемы. Не так много, что вы можете использовать в аппаратном плане, за исключением обновления до, возможно, процессоров Sandy/Ivy Bridge для повышения производительности на 20-50% по сравнению с поиском Btree и т. Д.

Обратите внимание, что моя сильная сторона - Innodb, поэтому я собираюсь

1. Не обращайте внимания на то, что вы myisam и ведите себя так, как будто это ничего не изменит.
2. Предположим, что эта проблема является достаточным стимулом, чтобы заставить вас обновить. Да, это обновление.

Innodb может помочь извлечь выгоду из всей этой памяти, храня эти часто используемые строки в своем пуле буферов. Вы можете настроить его так, чтобы он был настолько большим, насколько вы хотите (скажем, 80% памяти), и новые операции чтения / записи останутся в памяти до тех пор, пока не потребуется перенести их на диск, чтобы освободить место для последних доступных данных. В памяти это на порядок быстрее, чем у ваших FusionIO.

Есть много других функций Innodb, таких как адаптивные хеши, механизмы автоматической блокировки и т. Д., Которые могут быть благом для вашей среды. Вы, однако, знаете свои данные лучше, чем я.

В мире innodb хорошим краткосрочным решением является оптимизация вашего ведомого устройства - вам действительно нужны все индексы на ведомом устройстве, которые есть на вашем ведущем устройстве? Индексы - это шарик и цепочка на вставках / обновлениях / удалениях, ДАЖЕ с картами Fusion IO. IOPS не все здесь. Мосты Sandy/Ivy Bridge имеют намного лучшую пропускную способность памяти и производительность вычислений - они могут иметь огромное значение для Westmeres, который вы сейчас имеете. (Рисунок 20-50% в целом). Удалите все индексы, которые вам не нужны на ведомом устройстве!

Во-вторых, и почти наверняка применимо только к innodb, mk-prefetch может знать, какие обновления и до того, как ведомый записывает их. Это позволяет mk-prefetch сначала выполнить запрос на чтение, тем самым вынуждая данные находиться в памяти к моменту, когда отдельный реплик выполняет запрос на запись. Это означает, что данные находятся в памяти, а не в fusionIO, что дает быстрый прирост производительности. Это имеет огромное значение, больше, чем можно было бы ожидать. Многие компании используют это как постоянное решение. Узнайте больше, ознакомившись с инструментарием Percona.

В-третьих, и, самое главное, после того, как вы перейдете на Innodb, обязательно оформите Tokutek. У этих ребят есть несколько потрясающе крутых вещей, которые намного превышают производительность записи / обновления / удаления Innodb. Они отмечают повышение скорости репликации как одно из ключевых преимуществ, и из их тестов видно, что Fusions crazy IOPS все равно не поможет вам в случае Btrees. (Примечание: я не проверен независимо). Они используют вставную замену индекса btree, которая, хотя и ужасно более сложна, улучшает многие из алгоритмических ограничений скорости индексов btree.

Я нахожусь в процессе рассмотрения вопроса об усыновлении Tokutek. Если они освобождают так много скорости записи, это позволяет мне добавлять больше индексов. Так как они сжимают данные и индексы в таких замечательных соотношениях (25-кратное, по их словам), вы даже не платите (производительность, обслуживание) за увеличение объема данных. Вы платите ($) за их движок, хотя, $2500/ год за предварительно сжатый ГБ, IIRC. У них есть скидки, если у вас есть реплицированные данные, но вы можете даже просто установить Tokutek на своем подчиненном устройстве и сохранить ваш мастер как есть. Ознакомьтесь с техническими подробностями в лекции MIT Algoritms Open Courseware. Кроме того, у них есть тонны технических вещей в их блоге и регулярные технические документы для тех, у кого нет 1:20 для просмотра видео. Я полагаю, что это видео также дает формулу Big-O для того, как быстро читается. Я должен предположить, что чтение происходит медленнее (всегда есть компромисс!), Но формула слишком сложна, чтобы я мог оценить, сколько. Они утверждают, что это примерно то же самое, но я бы лучше понял математику (маловероятно!). Вы можете оказаться в лучшем положении, чтобы обнаружить это, чем я.

Ps Я не связан с Tokutek, я никогда не запускал их продукт, и они даже не знают, что я смотрю на них.

Обновление:

Я вижу, у вас есть другие вопросы на этой странице, и я подумал:

Во-первых, ведомая предварительная выборка почти наверняка не подойдет для myisam, если у вас нет исключительной среды. Это происходит главным образом потому, что предварительная выборка будет блокировать те таблицы, в которые вы собираетесь писать, или у ведомого потока заблокирована таблица, необходимая демону предварительной выборки. Если ваши таблицы очень хорошо сбалансированы для репликации, а разные таблицы пишутся в циклическом порядке, это может сработать, но имейте в виду, что это очень теоретически. Книга "High Performance Mysql" содержит дополнительную информацию в разделе "Проблемы с репликацией".

Во-вторых, предположительно, ваш ведомый имеет нагрузку 1,0-1,5, он может быть выше, если у вас запущены другие процессы или запросы, но базовый уровень 1,0. Это означает, что вы, скорее всего, связаны с процессором, что, вероятно, с вашим FusionIO на борту. Как я упоминал ранее, Sandy/Ivy Bridge собирается дать немного больше веселья, но, вероятно, этого недостаточно, чтобы провести вас через более грубые времена с минимальной задержкой. Если нагрузка на это ведомое устройство в основном предназначена только для записи (то есть, не много операций чтения), ваш ЦП почти наверняка тратит свое время на вычисление позиций для вставок / удалений btree. Это должно подкрепить мою мысль об удалении некритических индексов - вы всегда можете добавить их позже. Отключение гиперпоточности не сработает, больше ЦП не ваш враг. Как только вы получите более 32 ГБ оперативной памяти, скажем, 64 ГБ, вам нужно беспокоиться о распределении оперативной памяти, но даже тогда симптомы будут другими.

Наконец, и самое главное (не пропустите эту часть;)), я предполагаю, что вы сейчас запускаете RBR (репликацию на основе строк), потому что вы упомянули нетривиальное повышение производительности при его переключении. Однако здесь может быть способ получить еще большую производительность. Ошибка MySQL 53375 может проявиться, если у вас есть реплицируемые таблицы без первичного ключа. Ведомый в основном не достаточно умен, чтобы использовать что-либо кроме первичного ключа, поэтому его отсутствие заставляет поток репликации выполнять полное сканирование таблицы для каждого обновления. Исправление - просто добавление мягкого, суррогатного автоинкрементного первичного ключа. Я сделал бы это только если бы таблица была большой (скажем, несколько десятков тысяч строк или больше). Это, конечно, происходит за счет наличия другого индекса на столе, который поднимает цену, которую вы платите в CPU. Обратите внимание, что теоретических аргументов против этого очень мало, поскольку InnoDB добавляет один закулисный, если вы этого не сделаете. Призрачный, однако, не является полезной защитой от 53375. Вольфрам также может решить эту проблему, но вы должны быть уверены, что при использовании вольфрама у вас правильная кодировка. В последний раз, когда я играл с ним, он ужасно умирал, когда любая реплика не-UTF8 требовала репликации. Это время, когда я отказался от этого.