Комментарии 36
Для полного камильфо системы апрува привязываются к телеграмму или простым мэилам.
Как следствие накопленную базу плановых работ применяем к:
1. KPI для инженеров и проектов
2. База знаний для последующих работ
3. History лог для компаний
4. Расчет временных рамок работ для биллинга непосредственно для каждой компании
За статью спасибо, нравится когда люди анализируют ошибки
спасибо за коммент, приходите к нам в uptime.community поговорить ;), можно в телеграм канале telegram.me/uptime_community
можно в фб www.facebook.com/groups/uptime.community
работу над ошибками проводили плотную и со всеми.
один раз ошибается каждый, и чаще всего — это из-за ошибок в процессах в компании
можно было бы опасаться за то, что такое повторится, но человек опытный а работа шла в огне.
Если бы я оказался админом из первого случая (а подобную ошибку в запарке любой может допустить), я бы и безо всяких прощений-непрощений хотел бы сделать себе харакири. :-)
Тут важно не наказывать, а разобрать кейс и изменить процессы таким образом, чтобы подобное не повторилось.
Самое важное — здравый смысл, ответственность и умение думать наперед. А если у админов имеется такое качество как недоверчивость и желание перепроверить свои действия — то это замечательный администратор, на которого можно положиться.
Но от человеческого фактора избавиться невозможно, поэтому в бюджет компании следует закладывать такие неприятности :)
Способы снятия бэкапа, конечно же, обсуждались разные. И как в самом начале заметки говорилось, база у клиента была немаленькая, больше 2Тб. Никакого локального хранилища с толстым каналом, к сожалению, рядом не было. А на 100Мбитах тащить такой объём данных — это больше трёх суток в идеальных условиях. Т.е. «за пару часов вечером после шести» это было, увы, не решить.
Потому и было принято решение снимать бэкап в фоне экстрабэкапом.
Вероятно я не в курсе каких-то тонкостей, но вот эти мысли приходят в голову в первую очередь.
Ну или вы там про отсутсвие слейва говорили — а почему бы его не поднять? После 18 же можно перезапустить MySQL?
А почему ibdata у процесса xtrabackup оказался помечен как deleted?
Ведь админ занулял только удаленные файлы.
for i in 'lsof -p id_xtrabackup| grep -i dele' ; do echo ""> /proc/id-mysql/fd/$i ; doneИ вместо id-mysql нужно было подставить айдишник экстрабекапа. Но увы.
Ну так это меняет дело. Я не понял этого при чтении статьи. Это меняет ситуацию с "Админ кое-чего не знал, а потому не очень виноват" на "Админ допустил явную ошибку и стопроцентно виноват". Напишите это в тексте статьи, желательно прямо приведя эту команду (пускай она приблительная), ну или сославшись на этот ваш комментарий. В тексте статьи написано:
Но, к сожалению, в тот момент не все наши администраторы знали, что когда xtrabackup работает (по сути, это такой дампер MySQL), он создает временный лог, и довольно хитро – он создает его как файл, который открывает на чтение и запись, и немедленно удаляет
Я сделал из этого комментария вывод, что админ не знал, что xtrabackup создаёт этот временный лог, и что именно это и было причиной "трагедии". Ну имеет право человек не знать? Не все же всезнайки. Так что админа можно понять. Но сейчас вы объясняете, что там дело не в незнании этого, а в банальном баге, когда вместо одного PID указан другой. Тут уже на незнание списать нельзя. Это явная ошибка, и админ явно виноват.
Также в вашей статье написано следующее:
Админ, запуская скрипт, зануляющий уже предписанные файловые дескрипторы, запустил его по pid MySQL и убил ibdata, которая весила 200—300 ГБ.
Так вот, при первом чтении я это предложение попросту не понял, а потому пропустил. А вот уже сейчас, при написании этого комментария, я прочитал его ещё раз, и наконец понял. В общем, "запустил его по pid MySQL" — это вообще какая-то мутная фраза. Как можно запустить по? Тут управление глагола нарушено, как сказали бы лингвисты. Надо сказать, например, запустил для. А лучше: "запустил для PID MySQL вместо PID xtrabackup". Ещё лучше: "написал PID MySQL вместо PID xtrabackup, хотя номера файловых дескрипторов брались у процесса xtrabackup".
Ещё один момент. Вы скажете, мол, хоть админ и написал один PID вместо другого, он всё равно не совсем виноват, т. к. ошибиться может любой. Так вот, да, возможно. Но есть принципиальная разница между тем, чтобы просто не знать, что у xtrabackup невидимый растущий лог, и тем, чтобы написать один PID вместо другого. Во втором случае можно придумать меры, которые гарантированно не позволили бы ошибиться. Например, принять правило о том, что любая команда и любой скрипт, запускаемый в продакшене, должен быть проверен ещё одним человеком, кроме того, кто её/его запускает. Или принять правило о том, что нельзя набирать команды на проде. Вместо этого их нужно копировать из заранее приготовленного документа, набранного в текстовом редакторе (именно такое решение приняли в Gitlab после одного инцедента). Или принять правило о том, что нельзя программировать на bash, и что вместо него нужно всегда использовать, скажем, python. И даже нельзя набирать сколько-нибудь сложные команды в командной строке bash. То есть apt-get install mc набирать можно. Но вот любую команду, содержащую "for" писать уже нельзя. Хочешь написать "for"? Нельзя, руки оторву. Напиши скрипт на python вместо однострочника на bash. Пускай даже этот скрипт на python будет на целый экран
с момента события сразу сообщили о том, что происходит и продолжали поддерживать связь до исправления (это каждые 10 минут в следующие два дня).
клиенты оказались понимающие, бэкапы с той операции стали сниматься (а до этого не снимались год или больше и предыдущие специалисты говорили, что бэкапы снять нельзя)
мы обсудили, что один раз накосячить можно и работу продолжили
спасибо клиентам, отношения сейчас очень хорошие
Как человек который постоянно сталкивался с нехваткой места — в первом случае у вас виноват не админ который удалил, а тот кто решил использовать этот ограниченный объем, то есть....
А менеджер — у своего менеджера? Через полгода, глядишь, можно и приступать к работе.
Если вы фриленсер и работаете с 5-10 постоянными клиентами то вы сам себе менеджер фактически. Вы все сами помните. Сами общаетесь с клиентами, выясняя все нюансы. Сами являетесь гарантом.
А теперь поднимаемся вверх и смотрим масштабы работы предприятия.
Вы предлагаете отдать все на откуп только одному админу? И зачем тут будент нужна фирма как таковая?
Всего-то надо было включить бинарный лог, а потом сделать обычный дамп с сохранением отметок из бинарного лога. Типа так:
mysqldump --single-transaction --flush-logs --master-data=2 --all-databasesВ начале лога будет писаться что-то типа такого:
-- CHANGE MASTER TO MASTER_LOG_FILE='mysqld-bin.089207', MASTER_LOG_POS=107;Потом этот дамп заливаем на слейве и запускаем репликацию, указывая начало в логе на мастере командой выше.
Да, конечно, всё это будет не быстро. Но наверняка.
--single-transaction
This option sets the transaction isolation mode to REPEATABLE READ and sends a START TRANSACTION SQL statement to the server before dumping data. It is useful only with transactional tables such as InnoDB, because then it dumps the consistent state of the database at the time when START TRANSACTION was issued without blocking any applications.
Какие слова или фразы из этой цитаты из документации наталкивают вас на идею блокировки базы?
Для первичного бэкапа на слейв есть целый набор ключей для автоматизации этого счастья.
--single-transaction в первом комментарии проглядел:)Но в целом, это не отменяет того, что экстрабэкап делает, в общем-то, то же самое, только другими средствами. Ну и интересен ещё вопрос скорости выполнения на таком большом объёме данных.
Это же сначала надо в дамп это всё снять, потом преобразовывать обратно уже не слейве. Всё это время на мастере должны храниться бинлоги с самого начала, чтобы можно было нормально подцепить слейв. Что в условиях ограниченного хранилища тоже вызывает сложности.
В общем, «Всего-то надо было» звучит слишком оптимистично в контексте ситуации:)
Экстрабэкап может и отработал быстрее (только не отработал!), но в отличии от него обычный дамп не вызвал бы никаких вопросов у пришедшего по тревоге администратора. Ему из вывода ps сразу всё было бы ясно и понятно. Делается бэкап.
В статье пишут что вот — не информировали других сотрудников, а я о том что можно и не информировать вовсе, если не делать неожиданных вещей без необходимости. Всего-то.
Хороший пост, все ошибаются. Но мне кажется, первая история немного про другое. Про то, что надо уметь говорить клиенту — нет. Не хочет выключать сервер и делать образ дисков, его нежелание понятно, но надо уметь настоять. Раз уж не сделали сразу по нормальному, кто-то должен страдать. Почему этим кто то должны были стать вы?
Про бэкапы, черную пятницу и коммуникации между людьми: как мы накосячили и научились больше так не делать