Pull to refresh
70
0
Олег Царёв @zabivator

Backend

Send message
package main

import (
    "io/ioutil"
)

func main() {
    ioutil.WriteFile("out.txt", []byte("Hello"), 0664)
}
Спасибо, советы я принял к сведению, и благодарен за них. Если когда-нибудь придётся снова работать с MySQL и критиковать его — учту.

> А если Вы и дальше будете рассказывать про «информативность» доклада, я начну перечислять все технические несуразности. И получится очень неловко.

Странно, вроде бы в самом начале я делаю оговорку: невозможно описать технически корректно и при этом наглядно, и описанное в докладе — лишь грубые схемы, которые позволяют ПРЕДСТАВИТЬ как всё работают, но на деле СЛОЖНЕЙ.
И оговорки в процессе доклада я тоже делаю.
Технических несуразиц там много, и я этого никогда не отрицал. Самое важное с моей точки зрения — оставить в голове слушателя картинку про журналы (что это такое и зачем нужно), какие они бывают, какие у них особенности.
Эта цель вполне достигнута, отзывы и обратная связь это потверждает.

За сим раскланиваюсь

P.S. спасибо за советы и критику, учту в будущем.
> Ну вот, как выяснилось, и зря не отслеживал.
Я предприму последнюю попытку объяснить, в общем-то, очевидные вещи.
На момент детального исследования параллельного slave я работал разработчиков проекта Target. В моих должностных обязанностях не было «разработки MySQL». Были конкретные проблемы проекта (отстающий slave на 5.5) и просили решения этих проблем.
Мер принято было много, в целом они помогли.
ОДНИМ ИЗ пунктов было изучения 5.7 (на дворе был 2014 год и 5.7.3) — поможет ли он с нашими проблемами или нет.
Мы провели ряд исследований, после коммуникаций с Oracle исправляли бенчмарки и повторяли исследования.
Никаких удовлетворительных результатов мы так и не получили, и ближе к концу лета 2014 года прекратили исследования.
Задач много других, 5.7.3 показал себя несостоятельным, имеющиеся проблемы смогли купировать другими способами (и на целый год этого даже хватило), я переключился на другие задачи.
Изученное и измеренное я оформил в виде доклада, доклад по отзывам людей, оказался информативным — «теперь мы наконец-то поняли, что происходит с репликацией, откуда наши проблемы и как с ними справляться». Минимум три success story есть, не считая отзывов вида «понял про репликацию и журналы из вашего доклада больше, чем после семестрового курса в ВУЗе».
Значит, доклад полезен людям

Вам не кажется странным, Алексей, критиковать мои действия с учётом данного контекста? Нигде, подчёркиваю — НИГДЕ — ни формально, ни по факту, ни в ожиданиях руководства не было слов о разработке MySQL. Только исследование, желательно — побыстрей, если не взлетает и непонятно что делать дальше — то забить, и работать над проблемами ПРОЕКТА.
А не MySQL.

> Кстати говоря, связался с разработчиками ты уже _после_ доклада. Это важно, и я об этом знаю точно.
У Вас, Алексей, неверная информация.
Я общался с Дмитрием Лёневым как минимум дважды:
1. На MySQL Meetup (которых был сильно раньше highload)
2. В процессе подготовки доклада к highload — он критиковал мой план доклада и дал много ценных замечаний
Но Вы «точно знаете», а с этим спорить бесполезно — успел убедиться за длительный промежуток времени
После доклада я просто повторил описание своего бенчмарка и выдал скрипты. User story: «нагруженный проект хочет смигрировать с 5.5 на 5.7 без даунтайма» я неоднократно описывал раньше.

Да, особенно круто критиковать доклад годовалой давности с современным MySQL. Впрочем, я почему-то не удивлён — ни подходом к критике доклада, ни повторения доклада (пожалуй, из неупомянутого мной лишь multi-source replication), ни личным выпадам.

Просто отмечаю: в третий раз за эту дискуссию пропускаю личные выпады и гипотезы с негативной коннотацией.

Оракл подробно запросил у меня детали бенчмарков и их смысл (для какой реальной задачи они нужны). Меня поблагодарили, ушли чинить.
Потом мне кидали ссылку на один пост про 5.7, но там без даталей было — из личного общения выяснил, что там был прирост что-то порядка единиц процентов на 128 тредов.
Начиная с этого момента тему в дальнейшем не отслеживал.
У Оракла есть все мои скрипты, описание бенчмарков, результаты измерений. Другими словами, полная информация.
Собственно, железо описано на 76 слайде, а все скрипты лежат тут: github.com/zamotivator/2014-highload-mysql
Конкретно мы с админами убили кучу времени на очень простой сценарий (по которому собирались мигрировать на 5.7) — берём мастер пишем бинлоги, потому запускаем догон слейва и проверяем, как быстро он догоняется.
Мои графики в презентации — это как раз время догона.
Слайды 76 и 77: www.slideshare.net/tsarevoleg/ss-40969331?related=1
описывают железо и там есть ссылка на github со скриптами и конфигами/

Это лишь один из кучи проведённых тестов, но очень важный — если 5.7 работает не лучше чем 5.5, то мигрировать на неё нет смысла — нету решения нашей самой больной проблемы.

Другой интересный тест — это догон слейва 5.7 с мастера 5.5 — он нужен для миграции без даунтайма — там всё тоже было очень печально, регрессия 40% по сравнению с 5.5
Впрочем, это было на 5.7 годичной давности, и я уже не работаю в компании mail.ru, где снова актуально перепроверить результаты на новой версии
Ну, пусть так. Только что делать с CPU-bound репликацией на нагруженных проектах — вопросов остаётся открытым
Да, я знаю workaround'ы — записать general query log, построить по каждому типу запроса сводную статистику average response time и total time, отранжировать и исправить/убрать запросы
Понятно, что можно базу распилить.
Но это выглядит немного эээ странно, — у мастера ещё большой запас по CPU и IO, а реплика уже сдохла.

Не было бы этой проблемы — не было бы моего доклада. И судя по фидбеку после доклада — многие с этим наелись, и как решать — никто не понимает
Ну, если так, то странно почему не упомянут разбор различных типов журналов (логический/физический), их компаративный анализ, а также бенчмарк MySQL 5.7

В причинах тормозов не разобрались — вы правы, однако у меня задачи в проекте стояли несколько отличные от «починить mysql».
И я до сих пор очень хочу увидеть исследование LOGICAL_CLOCK в 5.7, которое:
— показывает существенный прирост производительности репликации
— указано железо и настройки
— указаны числа в эксперименте

Сейчас 5.7 выглядит странно — вроде есть крутая фича, которая должна давать практически линейный прирост, но по факту я его даже измерить не смог
Света, самое печальное — я до сих пор не видел ни одного исследования slave_parallel_type=LOGICAL_CLOCK, где было бы существенное улучшение производительности, и где были бы приведены числа и настройки.

Т.е. девушка есть, но мы вам её не покажем.
Алексей, спасибо за краткий пересказ моего доклада, я буду это цитировать.
Боюсь, вы не понимаете всей проблематики и просто не тестировали ваш код под серьёзной нагрузкой — потому и не столкнулись с проблемами.
Смотрите мой комментарий ниже про B-Tree
которая пишется за неделю и занимает тысячу строк кода

Это неправда. Задам два простых вопроса: насколько консервативен алгоритм объединения страниц в вашей версии «на тысячу строчек кода» и как у вас дела c Point-In-Time-Recovery?

Давайте я просто покажу вам метрики из InnoDB
oleg@x200:~/mrg/mysql-5.5.39/storage/innobase
➜ sloccount {btr,page}/* 2>&1 | grep ansic
14506 top_dir ansic=14506
ansic: 14506 (100.00%)


15 тысяч строчек кода. Это без блокировок, транзакций и журнала. Просто B-Tree дерево.
MySQL 5.5.39
Ну, коллеги в мыле используют, с ними постоянно общаемся.
У PostgreSQL проблемы есть, но они не в генетике, как у MySQL
Зависит от конкретного альтера, но чаще нет, чем да.
Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.

Печально, что вы меня почти не слушали, и вместо попыток понять пытались мне объяснить, что я ошибся

По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.

Конечно, имеет. table inheritance для поддержания ссылочной целостности требует CHECK, а его нет.
Вы не поверите, в Oracle тот же самый алгоритм — Cascades

Information

Rating
Does not participate
Location
Amsterdam, Noord-Holland, Нидерланды
Works in
Date of birth
Registered
Activity