MySQL в жизни высоконагруженных финансовых...

1

MySQL в жизни высоконагруженных финансовых приложенийФедорков В.В. Москва 2K20

2

О чем будем говорить?• О том как жить с MySQL когда даунтайм стоит очень дорого.

• О стабильности

• О производительности

• О настройках

• Об оптимизации запросов

• О том как жить с двумя датацентрами

• А так же о том, что один в поле не воин

ECOMMPAY Database Meetup, Москва 2020

3

Почему я об этом здесь говорю?• Занимаюсь производительностью систем на основе MySQL c 2006г.

• В Percona, Sphinx, PalominoDB и ProxySQL

• Первый раз попал в офис EcommPay в августе прошлого года

• С октября работаю в EcommPay


4

• 50+ серверов баз данных

• 40k+ QPS на одну машину

• 5Tb+ данных на одном сервере

• 50Tb+ бекапов в сутки

Что для нас высокие нагрузки?


5

Стабильность?• Работа DBA очень похожа на работу уборщицы

• Пока все чисто, нас не видно

• Если где-то грязь – это наша недоработка

• Если с базой проблемы – мы в центре событий!

• Отличие в том, что пол неровный, вместо тряпки зубило и все это

происходит в виртуальной среде.

• И по хорошему, наша задача сделать не просто что бы было чисто, а

так, что все успешно добежали до стенда тестирования куда им

нужно


6

Проактивная работа• Быстрая реакция на инциденты это база, без нее никак.

• Но стабильность прежде всего обеспечивается проактивной

работой

• Подготовкой инфраструктуры

• Анализом нагрузки

• Оптимизацией запросов

• Тестированием и бенчмарками

• Работой с новой функциональностью на стороне кода


7

Инфраструктура• NO Single Point of Failure вплоть до ДЦ

• Все ДБ сервера стоят в паре <мастер>-<реплика>

• Трафик балансируется между мастером и репликой

• Все работает на ржавом железе

• С виртуализацией только когда нагрузки позволяют

• Два датацентра на расстоянии 10ms друг от друга


8

Репликация – это боль• Данные между датацентрами должны быть синхронны

• Сбой репликации -> старые данные в ДЦ -> ошибки приложения

• Галера не помогает и даже немножечко вредит

• Поэтому двунаправленная классическая асинхронная репликация

• pt-slave-restart + Alerting = выбор чемпионов

• С последующим анализом логов

• И полуавтоматическим исправлением расхождений


9

Анализ ситуации – что собираем.• Алерты, логи и postmortem это не просто слова.

• Прыгать на те же грабли два раза - непозволительная роскошь

• Для MySQL собираются:

• Счетчики MySQL (графана, шаблоны PMM)

• Статистика нагрузки OS и железа

• Статистика запросов

• Все что медленнее 100ms немедленно логируется

• innodb_status_output и innodb_status_output_locks по необходимости


10

Визуализация необходимаДо визуализации


11

Визуализация необходимаПосле визуализации


12

Визуализация нагрузки• Шаблоны PMM перекрывают 99% ежедневных потребностей

• Запросы: чтение / запись / DDL / Admin / Prepared

• CPU: общая, прерывания, iowait

• IO: reads, writes, throughput, IOPS

• Network: in / out / connections / aborted / retransmition

• Гранулярность графиков – чем меньше, тем лучше видны

короткие всплески

• И тем сильнее тормозит графана


13

Анализ ситуации – нагрузка• Общий тренд нагрузки

• Всплески активности

• Ищем источники

• Кроны

• Очереди

• «Живые» пользователи


14

Нагрузка: где предел?

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0

10

20

30

40

50

60

70

80

90

2 4 8 16 24 32 40 48 64 96 128 160 192 256 320

Врем

я о

тклика (

ms)

Запросы

(ты

сяч в

секунду)

Активные клиенты (потоки)


15

Анализ ситуации – запросы• Всплески «медленных запросов»

• Новый медленный запрос

• Старый медленный запрос

• Временный перегруз MySQL

• Сбой железа

• «Временные сетевые

затруднения»

• Детали – сначала в slow log’е

• Потом в кибане


16

Читал slow log – много думал # Schema: Database Last_errno: 0 Killed: 0# Query_time: 0.783257 Lock_time: 0.000305 Rows_sent: 360 Rows_examined: 399759 Rows_affected: 0

# Bytes_sent: 4764 Tmp_tables: 1 Tmp_disk_tables: 0 Tmp_table_sizes: 258064# InnoDB_trx_id: 10360A8176# QC_Hit: No Full_scan: No Full_join: No Tmp_table: Yes Tmp_table_on_disk: No# Filesort: Yes Filesort_on_disk: No Merge_passes: 0# InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000# InnoDB_pages_distinct: 5128SET timestamp=1980434228;SELECT DISTINCT id FROM (SELECT … xx.yy AS id, … FROM table xx WHERE xx.a = '181' AND xx.b = '1' AND xx.status = 'active') dctrn_result ORDER BY date1 DESC, date2 DESC LIMIT 18446744073709551615 OFFSET 0;


17

А что не так с этим запросом?# Schema: Database Last_errno: 0 Killed: 0# Query_time: 0.783257 Lock_time: 0.000305 Rows_sent: 360 Rows_examined: 399759 Rows_affected: 0

# Bytes_sent: 4764 Tmp_tables: 1 Tmp_disk_tables: 0 Tmp_table_sizes: 258064# InnoDB_trx_id: 10360A8176# QC_Hit: No Full_scan: No Full_join: No Tmp_table: Yes Tmp_table_on_disk: No# Filesort: Yes Filesort_on_disk: No Merge_passes: 0# InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000# InnoDB_pages_distinct: 5128SET timestamp=1980434228;SELECT DISTINCT id FROM (SELECT xx.a, xx.b, xx.e, xx.f, … xx.yy AS id, … FROM table xx WHERE xx.a = '181' AND xx.b = '1' AND xx.status = 'active') dctrn_resultORDER BY date1 DESC, date2 DESC LIMIT 18446744073709551615 OFFSET 0;


18

Главное оружие: EXPLAIN*************************** 1. row ***************************

id: 1select_type: SIMPLE

table: xxpartitions: NULL

type: refpossible_keys: PRIMARY, idx_a_b, idx_a_b_f_m, idx_a_b_c_d_status

key: idx_a_b_c_d_statuskey_len: 8

ref: const,constrows: 861300

filtered: 50.00Extra: Using index condition; Using where; Using temporary;

Using filesort1 row in set, 1 warning (0.01 sec)


19

Медленные запросы - индексыВыборка: a = ? AND b = ? AND c = ?

Индексы

1. (a,b,c)

2. (b,a,c)

3. (c,a,b)

4. (a,c)

равноценны?


20

Запросы - CardinalitySELECT COUNT(distinct a) as cnt FROM xx:

2444

SELECT COUNT(distinct b) as cnt FROM xx:

150

SELECT COUNT(distinct status) as cnt FROM xx:

2


21

Запросы – Selectivity: столбец aSELECT a, COUNT(*) as cnt FROM xx

0

100000

200000

300000

400000

500000

600000

700000

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Частоты значений А в таблице (всего 5121836 записей)


22

Запросы – Selectivity: столбец bSELECT b, COUNT(*) as cnt FROM xx

0

1000000

2000000

3000000

4000000

5000000

6000000

0 50 100 150 200 250 300 350

Частоты значений А в таблице (всего 5121836 записей)


23

Selectivity: statusSELECT status, COUNT(*) as cnt FROM xx

0

1000000

2000000

3000000

4000000

5000000

6000000

active deleted

Частоты значений status в таблице (всего 5121836 записей)


24

Выбор индекса• Первым ставим поле отсекающее наибольшую часть данных

• С учетом потенциальных «горячих» точек

• Учитываем сортировки

• Помним, что первичный ключ незримо присутствует

• Индекс не бесплатен

• Добавляет до нескольких процентов к времени вставки

• Увеличивает таблицу

• Могут быть варианты лучше


25

Все медленное починили!


26

Есть новости!!!• Тюнинга только медленных запросов – недостаточно.

• Большую часть времени базы могут тратить быстрые запросы

• Нужно включать полное логгирование.


27

Полное логирование• Может быстро закончится место на диске

• Может убить производительность диска

• Дает детальную статистику на момент сбора данных

• Позволяет быстро увидеть чем занят сервер

• Старый добрый pt-query-digest в помощь


28

Профиль нагрузки# Time range: 2020-01-32T12:21:40 to 2020-01-32T12:25:03# Attribute total min max avg 95% stddev median# ============ ======= ======= ======= ======= ======= ======= =======# Exec time 277s 1us 818ms 96us 287us 3ms 57us# Lock time 45s 0 810ms 15us 20us 3ms 0# Rows sent 1.99M 0 1.23k 0.73 0.99 9.34 0# Rows examine 13.91M 0 343.28k 5.09 0.99 562.38 0# Rows affecte 166.97k 0 1.00k 0.06 0.99 1.15 0# Bytes sent 1.97G 0 187.78k 739.72 2.89k 1.75k 88.31# Merge passes 0 0 0 0 0 0 0# Tmp tables 44.23k 0 1 0.02 0 0.12 0# Tmp disk tbl 1 0 1 0.00 0 0.00 0# Tmp tbl size 4.45G 0 758.05k 1.63k 0 19.62k 0# Query size 298.12M 6 9.91k 109.15 563.87 206.92 31.70# InnoDB:# IO r bytes 64.00k 0 16.00k 0.07 0 33.95 0# IO r ops 4 0 1 0.00 0 0.00 0# IO r wait 2ms 0 262us 0 0 0 0# pages distin 3.27M 1 6.68k 3.70 10.84 20.97 0.99# queue wait 0 0 0 0 0 0 0# rec lock wai 671ms 0 226ms 0 0 272us 0


29

Хит-парад запросов# Profile# Rank Query ID Response time Calls Item# ==== ================== ============== ======= ============# 1 0x99AA0165670CE848 126.4176 32.0% 1152741 UPDATE db1.table1# 2 0x813031B8BBC3B329 29.5214 7.5% 65293 COMMIT# 3 0x657B379F8BE9439C 24.5091 6.2% 42285 UPDATE db1.table2# 4 0x67BFB5AA766431E8 23.3710 5.9% 42285 INSERT db1.table1# 5 0x052BE56BFBD6FA86 14.1776 3.6% 106916 SELECT db2.table1# 6 0x111FD2D3F3B3B4EB 10.9522 2.8% 1152735 INSERT db1.table4# 7 0x64E0D90726CFA6DC 10.9052 2.8% 90148 SELECT db3.table1# 8 0x7CBD2A3E49D77CF5 9.2416 2.3% 39397 SELECT db1.table1# 9 0x2DF8D785B097BC96 7.0138 1.8% 62167 SELECT db1.table1# 10 0x70B45CDE756AA7F5 6.3765 1.6% 7450 SELECT UNION db1.table1 db1.table4# 11 0x4825E6154DD062DE 5.6855 1.4% 37583 SELECT # 12 0xC3698DA76656983A 5.1965 1.3% 54841 SELECT # 13 0x937FAF7CE7226811 4.8999 1.2% 33797 UPDATE


30

Хит-парад запросов# Query 3: 209.33 QPS, 0.12x concurrency, ID 0x657B379F8BE9439C at byte 699625474# This item is included in the report because it matches --limit. # Scores: V/M = 0.00 # Time range: 2020-01-32T12:21:43 to 2020-01-32T12:25:05 # Attribute pct total min max avg 95% stddev median # ============ === ======= ======= ======= ======= ======= ======= ======= # Count 1 42285 # Exec time 6 25s 83us 22ms 579us 799us 410us 541us # Lock time 3 1s 12us 4ms 26us 47us 38us 21us # Rows sent 0 0 0 0 0 0 0 0 # Rows examine 0 41.29k 1 1 1 1 0 1 # Rows affecte 18 41.29k 1 1 1 1 0 1 # Bytes sent 0 2.10M 52 52 52 52 0 52 # Merge passes 0 0 0 0 0 0 0 0 # Tmp tables 0 0 0 0 0 0 0 0 # Tmp disk tbl 0 0 0 0 0 0 0 0 # Tmp tbl size 0 0 0 0 0 0 0 0 # Query size 0 3.14M 75 80 77.99 76.28 0.13 76.28 # InnoDB: # IO r bytes 0 0 0 0 0 0 0 0 # IO r ops 0 0 0 0 0 0 0 0 # IO r wait 0 0 0 0 0 0 0 0UPDATE db1.table2 SET counter = counter + 1 WHERE shard = 12\G


31

Профайла нагрузки – недостаточно• В разных ДЦ запросы могут работать по-разному.

• Нужно ловить новые запросы

• pt-query-digest --review

• Нужно ловить изменение времени работы старых

• Потому что данные меняются

• В идеале нужно отлавливать резкие изменения данных

• Нужно понимать динамику изменений и прогнозировать нагрузку


32

Коммуникация – ключ к решению• Все знать – невозможно.

• Добавлять в тихую индексы – бестолково

• Разработчики знают как код ДОЛЖЕН работать

• Знают про новые функции

• Администраторы знают как он работает ПО ФАКТУ

• Сложность системы нужно последовательно уменьшать

• Не факт что функция нужна

• Не факт что все данные в таблице нужны

• Комплексные проблемы приложения в одиночку решить не

выйдет


33

Вопрос!

Можно ли тюнингом MySQL решить

проблемы производительности?


34

Тюнинг MySQL• Конфигурационных переменных: 574 (MySQL 5.7)

• Параметров файловой системы: 48 (ext4)

• Параметров ядра: 837 (sysctl -a)

• Файлов в /etc: 1986

• Кастомная сборка MySQL

• CPU & IRQ affinity, Timer interrupts и т.п.

• Собственноручно настроенное и скомпилированное ядро

• Переписанный scheduler операционной системы


35

Тюнинг MySQL• Если существенное время уходит на тюнинг – вы что-то делаете не так

• 5% настроек обеспечивают 95% производительности

• Чем меньше в конфиге – тем лучше.

• Что действительно нужно

• Память

• Сеть

• IO

• Репликация


36

Тюнинг MySQL: Память• innodb-buffer-pool-size

• innodb-buffer-pool-instances

• table-definition-cache

• table-open-cache


37

Тюнинг MySQL: Сеть• max-allowed-packet

• max-connect-errors

• skip-name-resolve


38

Тюнинг MySQL: IO• innodb-log-file-size

• innodb-log-files-in-group

• innodb-flush-log-at-trx-commit

• innodb_read_io_threads

• innodb_write_io_threads

• innodb_io_capacity

• innodb_io_capacity_max


39

Тюнинг MySQL: Репликация• log-bin

• server_id

• expire-logs-days

• sync-binlog

• GTID

• gtid_mode

• enforce_gtid_consistency


40

Минимизация времени downtime• В случае отказа реплики трафик перебрасывается на другую ноду

• В случае отказа мастера запись переключается на реплику

• Для контроля трафика используется балансировщик

• Размещение балансировщика прямо на клиенте решает несколько

задач

• Убирает SPoF на стороне хранилища данных

• Дает точную статистику использования базы по источнику

• Часть изменений в работе прямо сейчас


41

Хотите научиться – работать с MySQL– жить с высокими нагрузками– понимать как работают сложные финансовые информационные системы

Приходите к нам работать!

Date post:	11-Aug-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

MySQL в жизни высоконагруженных финансовых...

Documents