Databases

Feedback о курсе: - много текста на слайдах - люди сначала читают - перечитывать что написанно нет смысла)

Books:

По базам

понятие repeatable-read - когда во время чтения все фризится когда он вЫключен - какая-то таблица может обновляться в пределах транзакции, пока к ней не обратятся Но как все реально будет работать, зависит еще от того, как вы стартуете транзакцию Если у вас не транзакционная база - то это все не работает :) Собственно транзацции происходят в режиме copy-on-write по памяти

MySQL:

  • пересчитывает индексы в момент первого SELECT
  • поэтому если хотим скопировать - надо закрыть и на запись, и на чтение
  • Можно использовать blackhole движок для разгрузки мастера
    • тогда мастер пишет только бинлог
    • слейвы пишут данные
    • только надо чтобы изменение движка не среплицировалось на slave
    • можно сделать для отдельной таблицы
    • и только если с мастера не читают
  • Выдачу прав юзера лучше делать тоже только через мастер и пусть он реплицирует на slave
  • Движок innodb при удалении данных из базы не удаляет по факту с диска. Лечится alter table
  • Фактически innodb растет бесконечно

Casandra

  • Синкает бин-лог
  • При старте сравнивает последний дамп и бин-лог, и то, что не было задамплено - доливает.
  • Может находится в различных точках CAP соттношения в различное время(availability/consistency/partion tolerance)
  • Использует протокол Glossy(сплетница)
  • При рассинхроне времени клатер уйдет в офлайн
  • Уровни записи и чтения:

System Message: WARNING/2 (<string>, line 44)

Bullet list ends without a blank line; unexpected unindent.
  • 1
  • Q (quorum)
  • A (all)
  • можно делать Q write and Q read
  • или A write and 1 read

Vertica

Колоночная Бесплатная до 1Tb (который по факту может быть меньше 500 Gb данных) Ппц как закрытая

Graphite Whisper

Может упираться в количество файлов на диски, которые он генерит Можно подменить файлы на что-то типа clickhouse метрики идут по UDP, поэтому могут не дойти Хорошо подходит для общего мониторинга Легче чем prometeus или InfluxDB

Prometeus, InfluxDB

Хорошо подходит для тех метрик, которые одни и теже и не меняются

Redis:

  • setup OVERCOMMIT=1

Mongo:

  • явно mongo.dump может не отработать
    • можно сделать полный replica-set базы и сделать слепок с него
    • или одна коллекция в один часть(но могут получится расхождения)
  • можно посмотреть на роутер mongos

Clickhouse

  • для метрик
  • база сама по себе “развернута”
  • колоночная база хранит время апдейта каждого столбца/поля?

Consul DataBase

Rabbit MQ как хороший messanger router

Наша хранилка

Разбивать на несколько рейдов, что бы мониторить нагрузку на каждый диск Для файлопомойки использовали ребята честный ZFS with Solaris NGinx -> прослойка -> файловая система Push и Pull модель Torrent с анонсером для синхронизации

SysCalls:

железка <- драйвер <- core Core выдает API SysCall:

  • open
  • write
  • lseek
  • etc.

lseek: проблема заключается в том, что мы должны не просто сдвинуться, но и выяснить место, куда надо сдвинуться. Т.е попутно мы еще много раз вызываем read, что бы найти свободное место.

Чем меньше ядро обращается к железу, тем лучше.

Практические аспекты

Соотношение скорости и надежности. Highload - когда мы не можем решить проблему стандартными подходами(в частности железом)

В общем современные данные состоят из: - файл с логом операций - собственно данные - различные индексы

Индекс позволяет узнать сразу куда сделать seek, что позволяет сделать его единожды.

Все взаимодествие между пользователем и базой(и на read и на write) проходит через оперативную память

Проблема репликаций баз, в слечае когда одна база отвалилась от сети, но что-то продолжает с ней работать. Поэтому получается сложно определить в случае двух нод, кто прав. Можно использовать какой-то подход 3й реплики или арбитра. Правило 2n + 1

Разные логические блоки можно держать вообще в отдельных базах(
например таблицы users и messages живут вообще в различных базах

System Message: WARNING/2 (<string>, line 139)

Definition list ends without a blank line; unexpected unindent.

)

При дебаге - надо знать что и откуда приходит. Хорошая практика - имень скрипт, который умеет лочить все порты кроме 22. И востанавливать все порты обратно.

Не завязывайся на “серую”(локальную) сеть.

Если у вас есть несколько баз данных - расселите их сразу на два отдельных процесса. Вы даже можете использовать одну визическую железку - но виртуально хранить отдельно. Когда придется разносить - к этому будете готовы и вы и разработчики.

Синхронная раздача connection strings?

“Хождение через океан” надо закладывать на уровне архитектуры еще на этапе разработке(очереди)

Приложение которое по сигналу (например SIGHUB) будет переинициализировать пулл коннектов к базе - будет невероятно круто

Открытый tcp-dump по ssh - это хуже чем забытый дома утюг

Удаление файла, с которым что-то работает не освободит место на диске, если дескриптор в пользующей программе не был закрыт.

Join не позваляет в будущем настроить шардинг. В зависимости от того, будет ли расти объем данных и придется ли поднимать шардинг на разных серверах.

Последовательная запись vs. произвольная запись

  • strace: трасировщик

    • Но не подключайтесь на проде, ибо это это дорого и нагружает базу данных

  • strace -ff -e lseek -p pidof mysql

    • Вообще можно подключаться не только к базам, но и к другим процессам. Например ssh

System Message: WARNING/2 (<string>, line 172)

Bullet list ends without a blank line; unexpected unindent.

https://wiki/File_descriptor#Operations_on_file_descriptors

Золотое правило реляционных баз данных - индексы и файлы с данными(одна нода) не должна весить более 200GB

Файлы с данными и AOF (binglogs, append и event логи)

Бинлоги можно читать глазами Бинлоги должны бить длинее чем бекап. Обычно - в дна раза длинее чем время бекапов. Иначе, мы просто не сможем востановить бекапы. Хорошая практика - ежедневная развертка бекапов для каких-то тестовых задач.

Денормализация

Анализ performance issues

  • apt-get install sysstat iotop iftop
  • cat /proc/cpuinfo
  • top (and press 1) (разделить по ядрам)
  • iostat -dx 1 (%util - колонка работы с диском)
  • iotop - top для дисков
  • iftop -i eth0 - мониторинг сети

By default сетевые карты(даже многокональные) - биндятся на 0е ядро. Можно настроить нормально и поднять производительность.

Память

  • Resident set size (RSS)
  • виртуальная память (VM)
  • copy-on-write method (позволяет копировать, но при этом использовать сходные части)
  • free -h (buff/cache)
  • Потеря page cache при потере питания
  • Вымывание page cache

Комманды - netstat -tulp - lsof -p PID (процессы, порты и файлы что юзает) процесс - type redis-server (similar to which) - ldd /usr/bin/redis-server (list used external libraries) - sysctl - configure kernel parameters at runtime

System Message: ERROR/3 (<string>, line 218)

Unexpected indentation.
  • sysctl -a

Если вы что-то запишете в файл и сразу отключе питание - то файл не запишется. Ибо syscall sfync просто не успеет отработать(не случится физическая запись как таковая)

Забитая память быстрее вымывает кеши -> чаще вызывает fsync() и пишет на диск

Итого запись в файл:

База -> кеш -> page cache -> raid cache -> контролер -> и наконец, физическая запись

Процессорное время, переключение контекста

TODO: посмотреть как и что можно смореть через TOP Ядро видит FUSE как приложение FUSE из-за этого добавяет дополнительное хождение vmstat -s - показывает переключение контекста (IRQ cpu ticks) vmstat -m | less

Swap

Swap есть смысл включать, если при алерте вы готовы изолировать базу и дать свопу рассасаться. Иначе - просто нет смысла. База все равно умрет, просто через какое-то время.

Summary

Мониторьте все что можно Диски - %util Память - мониторить размер page cache и сколько осталось Процессор - мониторить idle Для каждой базы - мониторьте свои важные метрики, наприиер - inno_db - транзакционная глубина(самое большое значение) Отставание репликаций

не особо важно - deploy, monitor - в чат Важное - на звонилку (https://cloud.google.com/spanner/, https://www.pagerduty.com/)

Аппаратная составляющая

Скорость RAID масива меряется по скорости самого медленого диска. У баз есть Hardware compatible list - его можно использовать что бы понимать на чем быстрее и лучше работает. Тем более для новых баз. А то будет как инструкция к салату “Шуба” Если не мониторить состояние дисков - то при подмене и восставлении диска в рейд - можно добить выжившие

Кластеризация и репликация & Топологии репликации

Если есть две ноды - то лучше это закольцевать, а не просто сделать master -> slave Можно делать фильтрации, что надо реплицировать, а что нет

System Message: ERROR/3 (<string>, line 272)

Unexpected indentation.
  • Пример с сырой статистикой, которые не реплицируются, а агрегируются скриптами, а потом уже записываются дальше

Мастер-мастер и мульти-мастер

MySQL после рассинхрона не съедется
  • Пример одного Я поисковика и системы звонков

System Message: WARNING/2 (<string>, line 279)

Definition list ends without a blank line; unexpected unindent.

Galera claster - медленно, но надежно

Балансировка между нодами клстера

Локальный HAPproxy на каждой машине - это круто. Тем более он поддерживает замену ip-шников Позволяет на гарячую подменить мастер. Просто закрыв networking на местер - тогда HAProxy автоматически все переведет на slave.

Тюнинг индексов

128 GB оперативки стоят дешевле чем хороший DBA, а приносят больше пользы))

Индексов должно быть мало - только те, которыми вы пользуетесь.
Потому что они должны up-to-date, и поэтому они каждый раз будут пересчитываться. Любой индекс - удар по производительности (insert and update). Можно по логам смотреть какие индексы используются и какие нет. Которые не используются - убрать
Настройка индекса по абсолютно разным данным(например время как стринга) - не эффективно.
Т.к на один индекс приходится одна запись. Можно сделать индекс с игнорированием минут и секунд - тогда он будет эффективен В тоже время когда под одним индексом очень много данных - тоже плохо

System Message: WARNING/2 (<string>, line 300)

Definition list ends without a blank line; unexpected unindent.

Короче - следите за длинной индексов Показать тебе может только explain

Бекапы

Инкрементальные бекапы - это галимая жадность)
Если же делать инкрементами - то надо время от времени делать опорные дампы

System Message: WARNING/2 (<string>, line 308)

Definition list ends without a blank line; unexpected unindent.

Лучше делать полный бекап и автоматически проверять его развертку Главное не просто делать бекапы, но и проверять их.

System Message: ERROR/3 (<string>, line 310)

Unexpected indentation.
Часто вместо бекапа внутри может оказаться просто сообщение об ошибке

System Message: WARNING/2 (<string>, line 311)

Block quote ends without a blank line; unexpected unindent.

Два канала слака: - Все о хороших бекапах - Все о плохих бекапах Credentials для бекапов - делайте на отдельном хосте

Разбитие разделов and Logical Volume Manager

Система - 32GB Swap - что-то Данные - 100GB После - ничего не размечать Тогда раздел с данными можно бужет увеличить

LVM - если снепшот не удался, то надо его сразу его удалить. Иначе снова будет эффект утюга из-за copy on write. LVM делает небольшой оверхед, но позволяет легче работать с разбиением разделов

Consul and HaProxy хороший must have

Натюрлих богдана хмельникцого Хмельной князь Телеграм Павла - @p01nt