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

У мене є серйозна проблема з продуктивністю реплікації 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% даних, що надходять. Я дивлюсь на принаймні двічі пише на машині Master найближчим часом, тому відчайдушно потрібен спосіб поліпшити продуктивність реплікації.

Машина A:

• Майстер
• 24 ГБ оперативної пам’яті
• 1,2 ТБ 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

Машина B:

• Раб
• 36 Гб оперативної пам’яті
• 1,2 ТБ 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, можливо для 20-50% кращої продуктивності від пошуку Btree тощо.

Зверніть увагу, що мій форте - це Innodb, тому я збираюся

1. Ігноруйте, що ви мійсам, і дійте так, ніби це не змінить значення.
2. Припустимо, що ця проблема є достатньою поштовхом для того, щоб вас оновили. Так, це оновлення.

Innodb може допомогти скористатися всією цією пам'яттю, зберігаючи ці часто доступні рядки у своєму буферному пулі. Ви можете налаштувати його так, як вам хочеться (скажімо, 80% пам’яті), а свіжі читання / записи залишаються в пам’яті до тих пір, поки не потрібно натиснути їх на диск, щоб зробити більше місця для останніх доступних даних. У пам'яті на порядок швидше, ніж ваші FusionIO.

Існує ще багато функцій Innodb, таких як адаптивні хеши, механізми блокування автоматичного включення тощо, які можуть стати користю для вашого оточення. Ти, проте, знаєш свої дані краще, ніж я.

У світі innodb хорошим короткостроковим рішенням є оптимізація свого раба - чи справді вам потрібен кожен індекс про вашого раба, який є у вашого господаря? Індекси - це куля та ланцюжок на вставках / оновленнях / видаленнях, НАДІЙ з картками Fusion IO. IOPS тут не все. Програми міст Sandy / Ivy Bridge мають набагато кращу пропускну здатність пам’яті та обчислювальну здатність - вони можуть змінити велику кількість ваших Вестмерів зараз. (Загальна цифра 20-50%). Видаліть усі потрібні вам індекси на підлеглому!

По-друге, і майже напевно стосується лише innodb, це те, що mk-prefetch може знати, які оновлення і до того, як підлеглий пише їх. Це дозволяє mk-prefetch спочатку запустити запит читання, тим самим змушуючи дані знаходитись у пам’яті до моменту, коли одиночне відбиття виконує запит запису. Це означає, що дані знаходяться в пам’яті, а не в fusionIO, швидкому порядку збільшення продуктивності. Це робить величезну різницю, ніж можна було очікувати. Багато компаній використовують це як постійне рішення. Дізнайтеся більше, переглянувши інструментарій Percona .

По-третє, і найголовніше, щойно перейшовши на Innodb, обов'язково замовте Tokutek. У цих хлопців є злісно приголомшливі речі, що довго перевершують продуктивність запису / оновлення / видалення Innodb. Вони покращають швидкість реплікації як одну з ключових переваг, і ви можете бачити, чому з Fusions божевільний IOPS все ще не допоможе вам у випадку з Btrees . (Примітка. Незалежно від мене перевірено.) Вони використовують вибудовуючу заміну індексу btree, який, хоча і жахливо складніший, покращує багато алгоритмічних обмежень швидкості btree-індексів.

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

Ps Я не пов'язаний з Tokutek, я ніколи не запускав їхній продукт, і вони навіть не знають, що я на них дивлюсь.

Оновлення :

Я бачу, що у вас є деякі інші запитання на цій сторінці, і я подумав, що я підключуся:

По-перше, раб попереднього вибору майже напевно не спрацює з мійсами, якщо у вас не буде виняткового середовища. Це здебільшого тому, що попереднє завантаження буде блокувати ті самі таблиці, в які ви маєте намір записати, або у підлеглому потоці стоїть заблокована таблиця, яка потрібна демону попереднього отримання. Якщо ваші таблиці надзвичайно добре збалансовані для тиражування, а різні таблиці записуються в круговій формі, це може спрацювати - але майте на увазі, це дуже теоретично. У книзі "Mysql з високою продуктивністю" міститься додаткова інформація в розділі "Проблеми з реплікацією".

По-друге, імовірно, ваш підлеглий містить навантаження 1,0-1,5, це може бути вище, якщо у вас запущені інші програми або запити, але базовий рівень 1,0. Це означає, що ви, ймовірно, пов'язані з процесором, що, ймовірно, з вашим FusionIO на борту. Як я вже згадував раніше, Sandy / Ivy Bridge збирається дати трохи більше oomph, але, мабуть, недостатньо, щоб пережити вас через більш суворі часи з мінімальним відставанням. Якщо навантаження на цей підлеглий здебільшого лише для запису (тобто не багато читає), ваш процесор майже напевно витрачає час на обчислення позицій для вставки / видалення btree. Це повинно посилити мою думку щодо видалення некритичних індексів - ви завжди можете їх знову додавати пізніше. Відключення гіпертрейдування не вийде, більше CPU не ваш ворог. Як тільки ви отримаєте вище 32 ГБ оперативної пам'яті, скажімо, 64 ГБ, вам потрібно потурбуватися про розподіл оперативної пам'яті, але навіть тоді симптоми різні.

Нарешті, і найголовніше (не пропускайте цю частину;)), я припускаю, що зараз ви запускаєте RBR (реплікацію на основі рядків), оскільки ви згадали про нетривіальне підвищення продуктивності при переключенні на нього. Однак - тут може бути спосіб досягти ще більшої продуктивності. Помилка Mysql 53375 може виявлятися, якщо у вас є копії таблиць без первинного ключа. В основному ведений не є достатньо розумним, щоб використовувати що-небудь, крім первинного ключа, тому відсутність одного змушує нитку реплікації робити повне сканування таблиці для кожного оновлення. Виправлення - це просто додавання доброякісного сурогатного первинного ключа. Я зробив би це лише в тому випадку, якщо таблиця була великою (скажімо, декілька 10-ти тисяч рядків і більше). Зрозуміло, це пов'язано з тим, що на столі буде інший індекс, який відображає ціну, яку ви платите в процесорі. Зауважте, що дуже мало теоретичних аргументів проти цього, оскільки InnoDB додає один за кадром, якщо цього не зробити. Однак фантом не є корисною захистом від 53375. Вольфрам теж може подолати цю проблему, але при використанні вольфраму вам потрібно бути впевненим, що кодування прямо. Востаннє, коли я грав з ним, він би жахливо помер, коли будь-який рядок без UTF8 потребував реплікації. Це приблизно час, коли я від неї відмовився.

не відповідь, але ви можете розглянути реплікатор вольфраму та їх комерційні продукти для більшої гнучкості. це 100% використання процесора на одне ядро, що є вузьким місцем?

Отже, якщо ви робите резервні копії на підлеглому .. і ви використовуєте таблиці міазми .. ви блокуєте таблиці, щоб зробити резервні копії, щоб запобігти корупції. Тому реплікація не може працювати, поки резервна копія не завершена .. тоді вона наздоганяє.