У меня серьезная проблема с производительностью репликации MySQL 5.5 между двумя компьютерами, в основном таблицами myISAM с репликацией на основе операторов. Двоичные журналы и каталог данных mysql расположены на одном и том же Fusion ioDrive.
Проблема была большой проблемой в последнее время, когда нам нужно было приостановить репликацию на ок. 3 часа. Потребовалось около 10 часов, чтобы наверстать упущенное без дополнительной нагрузки.
Как я могу увеличить производительность репликации? Машина B в основном простаивает (мало, IO, 2 из 16 ядер, много свободной оперативной памяти), так как только 1 поток mySQL записывает данные. Вот несколько идей, которые у меня были:
- Переключитесь на репликацию на основе строк. В тестах это только дало прирост производительности на 10-20%
- Обновление до MySQL 5.6 с многопоточной репликацией. Мы могли бы легко разделить наши данные на отдельные базы данных, и тесты, кажется, указывают, что это помогло бы, но код не кажется готовым к работе.
- Некоторые переменные конфигурации, которые помогут ускорить репликацию
Основная проблема том, что если после паузы в течение 3 часов требуется 10 часов, это означает, что репликация записывает 13 часов данных за 10 часов или может записывать со скоростью 130% от скорости поступления данных. по крайней мере, двойная запись на главном компьютере в ближайшем будущем, поэтому отчаянно нужен способ улучшить производительность репликации.
Машина А:
- Мастер
- 24 ГБ оперативной памяти
- 1.2TB Fusion ioDrive2
- 2x E5620
- Гигабитное соединение
my.cnf:
[mysqld]
server-id=71
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp
log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306
log-bin=/data_fio/mysqlbinlog/mysql-bin.log
binlog-format=STATEMENT
replicate-ignore-db=mysql
log-slave-updates = true
# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000
# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32
user=mysql
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
Машина Б:
- рабыня
- 36 ГБ оперативной памяти
- 1.2TB Fusion ioDrive2
- 2x E5620
- Гигабитное соединение
my.cnf:
[mysqld]
server-id=72
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp
log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306
# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000
# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32
user=mysql
symbolic-links=0
plugin-load=archive=ha_archive.so;blackhole=ha_blackhole.so
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
Ответы:
Вау, у вас есть какое-то ужасное оборудование для этой проблемы. С аппаратной точки зрения не так уж и много, за исключением обновления до, возможно, процессоров Sandy / Ivy Bridge, чтобы повысить производительность поиска на Btree на 20-50% и т. Д.
Обратите внимание, что моя сильная сторона - Innodb, поэтому я собираюсь
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 строка нуждалась в репликации. Это время, когда я отказался от этого.
источник
не ответ, но вы могли бы рассмотреть вольфрам репликатор и их коммерческие продукты для большей гибкости. является ли узким местом использование 100% процессоров на одном ядре?
источник
Поэтому, если вы делаете резервные копии на ведомом устройстве ... и используете таблицы myiasm ... вы блокируете таблицы для создания резервных копий, чтобы предотвратить повреждение. Таким образом, репликация не может работать, пока резервное копирование не будет завершено .. тогда оно догоняет.
источник