company_banner

Про бэкапы, черную пятницу и коммуникации между людьми: как мы накосячили и научились больше так не делать

    13 октября мы провели вторую конференцию сообщества Uptime. В этот раз дата проведения выпала на пятницу 13-е, поэтому основная тема — аварии, и как с ними справляться. Это первый из серии постов про доклады с прошедшей конференции.


    У меня есть три страшные истории о том, как по нашей вине все сломалось, как мы это чинили, и что мы делаем теперь, чтобы это не повторилось.


    Uptimeday2-Potapov


    Масштаб: количество алертов


    Мы работаем с 2008 года, нас сейчас 75 человек (Иркутск, Питер, Москва), мы занимаемся круглосуточной технической поддержкой, системным администрированием и девопсом для веб сайтов по всему миру. У нас 300 клиентов и 2000 серверов на поддержке.


    Основная наша работа заключается в том, что если происходит какая-то проблема, мы должны за 15 минут прийти и исправить ее.


    В 2010 году было порядка 450 алертов в месяц в пике.



    Эта маленькая красная линия — это то, сколько алертов у нас было до конца 2012 года.
    В 2015 году — в пике доходило до 100 000 алертов в месяц.
    Сейчас их приблизительно 130 000 — 140 000.



    На наших дежурных приходит около 400 алертов в час. То есть 400 сообщений от системы мониторинга, которые нужно расследовать. Это может быть что-то довольно простое: к примеру, заканчивается место на диске; а может быть что-то сложное: все упало и ничего не работает, и нужно понять, что вообще случилось.



    В «черную пятницу» у нас доходит до 900 алертов в час, хотя интернет магазины готовятся к этому событию и предупреждают администраторов. Три года назад «черная пятница» проходила в пятницу. Два года назад магазины решили обхитрить друг друга и сделали «черную пятницу» в четверг, все вместе. В прошлом году это была среда, очевидно, что эта «черная пятница» будет во вторник и, в конечном счете, все пройдет по кругу. Магазины не любят говорить, когда именно это произойдет, поэтому хорошие магазины готовятся к нагрузочному тестированию, а другие хорошие магазины не говорят об этом вообще, а после приходят и говорят: «Здравствуйте, мы только что сделали рассылку на 300 000 человек, пожалуйста, подготовьте сервер к нагрузке».


    Если готовить сервер к нагрузке второпях, то возникает куча проблем. Уметь быстро соображать в таких условиях — особое умение. Обычно люди хотят работать по плану, им нужно хорошенько обдумать то, что они собираются сделать. Но в нашем случае это больше напоминает хирургическое отделение на поле боя.


    Аварии


    Алертов много, поэтому ошибки неизбежны. И иногда в процессе исправления одной проблемы, можно создать гораздо большую.


    Мы разделяем наши ошибки на три категории:


    1. Отсутствие процесса: случилась что-то, с чем мы раньше не сталкивались, что именно делать непонятно, пытаемся исправить на ходу — становится хуже.
    2. Ошибки в уже отлаженном процессе: с проблемой уже вроде бы знакомы, вроде бы понятно что надо делать, но не были предусмотрены все возможные варианты.
    3. Ошибки взаимодействия: вроде бы процесс отлажен, но есть проблема коммуникации между людьми.

    И у меня есть страшная история по каждому пункту.


    Отсутствие процесса


    Первая — одна из самых страшных историй, которые с нами происходили. Она случилась 31 марта 2016 года. К нам пришел клиент на поддержку, с 2 ТБ базой данных в MySQL без единого бэкапа, с 70 сотрудниками, которые работали на этой базе. Она была довольно сложной: где-то 300 ГБ на одну таблицу, сотни миллионов записей в таблицах. Вся компания работает только потому, что эта база существует.


    Отдельная проблема — предыдущие администраторы строили flashcache на диске и иногда файлы удалялись, иногда нет, происходило что-то странное.


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


    У базы нет слейва и люди работают с 9 до 18 с этой базой очень плотно — работу останавливать нельзя. В базе есть 300 ГБ MyISAM таблиц и xtrabackup, который хорошо бэкапит InnoDB, но лочит все на моменте бэкапа MyISAM. То есть мы сначала пытались запустить xtrabackup и посмотреть что будет. Xtrabackup заблочил MyISAM таблицы, сайт лег, все перестало работать.


    Мы отменили запуск xtrabackup и стали думать что делать. У нас есть xtrabackup, который хорошо работает с InnoDB и который плохо работает с MyISAM. Но MyISAM в данном случае оказался не так уж и нужен в самом бэкапе. План был такой: мы запустим xtrabackup вручную без MyISAM части. Перенесем данные на слейв, со слейва поднимем еще один слейв, который будем просто дампать копированием.


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


    В два ночи я сам запустил xbackup, распотрошив бэкап так, чтобы он не делал ничего связанного с MyISAM и просто переливал данные. Но, к сожалению, в тот момент не все наши администраторы знали, что когда xtrabackup работает (по сути, это такой дампер MySQL), он создает временный лог, и довольно хитро – он создает его как файл, который открывает на чтение и запись, и немедленно удаляет. На диске этот файл найти нельзя, но он растет и растет. При этом xtrabackup его не стримит на другой сервер. Соответственно, если записей очень много, то место на диске быстро кончается. Об этом к нам в 16 часов пришел алерт.


    На сервере стало мало свободного места, и админ пошел разбираться, что происходит. Он увидел, что место заканчивается, а чем оно забито – непонятно. Зато есть xtrabackup, у которого есть «deleted file», который имеет к этому какое-то отношение. И решил, что это удаленный лог, случайно открытый xtrabackup’ом и нужно бы его занулить.


    Админ написал скрипт, который читал файлы-дескрипторы, открытые xtrabackup’ом, и занулял все файлы с пометкой «deleted». Запустил скрипт в 18:00, и сайт немедленно упал.


    К 18:30 мы понимали, что MySQL не поднимается и не отвечает. В это время я ехал на машине из Новосибирска, где я был на конференции, к друзьям в Барнаул. С друзьями я посидел буквально пять минут, потому что мне позвонил клиент и сказал, что в результате безобидной вроде бы операции, внезапно лег сайт. Я заглянул в чат админов. И увидел там фразу: «Ну, мы же не убили им базу». Ответ был: «Да, убили. И возможно с концами».


    Админ, запуская скрипт, зануляющий уже предписанные файловые дескрипторы, запустил его по pid MySQL и убил ibdata, которая весила 200—300 ГБ.


    После небольшой паники я пришел к клиентам и сказал что произошло. Это был трудный разговор. К 19 часам мы поняли, что xtrabackup успел перелить ibdata.


    В MySQL есть старая структура данных, когда все лежит в одном файле в ibdata, и есть отдельная новая структура InnoDB, где таблицы лежат в отдельных файлах. В ibdata, к сожалению, по-прежнему лежат «last sequence numbers», то есть MySQL запускается, смотрит в каких позициях в файлах лежат данные, идет туда и тогда все хорошо, если ibdata нет – MySQL не запускается. Вообще.


    У нас была перелитая на горячую ibdata, мы пытались просто подсунуть ее, но MySQL data recovery с этой таблицей работать отказался. Понятно было что наверное что-то сделать можно, но что именно – непонятно.


    Мы позвонили в известную компанию, которая связана с MySQL, и, в том числе, занимается восстановлением данных. Мы сказали, что у замечательная ситуация: есть 2ТБ база с 300GB таблицами и убитой ibdata. Есть еще отдельная ibdata, которая скопирована на горячую и мы бы очень хотели, чтобы они попытались восстановить эту базу. Нам ответили, что посмотреть можно, но это стоит $5 000. Поскольку косяк был страшный, я спросил, куда платить, после чего оказалось, что $5 000 — это fuck off money этой компании, работать они все равно отказались. Как я потом узнал, когда мы описали всю проблему, ребята из этой компании долго спорили, сможем ли мы восстановить эту базу.


    К 21 часу мы нашли блог человека по имени Александр Кузьминский, который до этого тоже работал в компании, куда мы обратились. Он очень крутой, я его недавно видел, 50 раз сказал ему спасибо. В его блоге было написано, что если вы случайно удалили ibdata, и при этом у вас есть скопированная на горячую ibdata, вы можете ее поставить на место, запустить MySQL под gdb, и во время запуска оперативно в памяти менять неправильные значения «last sequence numbers» на правильные.


    Нам очень хотелось вернуть базу, потому что все предыдущее время до этого я думал, что мы только что уничтожили компанию, в которой работает 70 человек. В итоге мы попробовали сделать как было написано, и оно запустилось. К сожалению, MySQL запускается в recovery mode и туда, естественно, ничего нельзя писать, да и вообще страшно. Поэтому мы решили, что базу надо задампать. На этот раз мы делали это MySQL-дампом. Поэтому следующие двое суток мы дампали потаблично всю базу, и надеялись, что все заработает. Заработало.


    Мы решили, что отныне мы будем проводить анализ инцидентов.


    Эмоций было очень много, но давайте рассмотрим все чуть более отстраненно.


    Что именно случилось?


    Дано:


    2016-03-31
    - Клиент пришел на поддержку без бэкапов БД
    - Размер БД (MySQL) — 2ТБ, около 300гб на таблицу
    - Нет слейва, работу останавливать нельзя
    - 300гб MyISAM (лок xtrabackup)

    План:


    2016-03-31
    - Запускаем xtrabackup вручную, без MyISAM части
    - Переносим данные на слейв, поднимаем слейв со слейва
    - Последующие бэкапы – остановка второго слейва

    Жизнь:


    2016-03-31 02:00    запуск xtrabackup
    2016-03-31 02:00 — 2016-04-01 16:00    рост (deleted) redo-log-а
    2016-04-01 16:00    алерт «мало места на диске»
    2016-04-01 17:00    ответственный администратор не знает о redo-log-е, решает чистить (deleted) xtrabackup, создает скрипт для зануления file-handler-а с (deleted)
    2016-04-01 18:00    ответственный администратор запускает скрипт
    2016-04-01 18:00    сайт недоступен

    Спасение:


    2016-04-01 18:00 — 18:30    MySQL упал и не запускается
    2016-04-01 18:30    зануленный file handler был ibdata процесса MySQL
    2016-04-01 19:00    остался скопированный нагорячую ibdata в куске xtrabackup дампа
    2016-04-01 20:00    компания data recovery MySQL отказывается работать в такой ситуации
    2016-04-01 21:00    пост в блоге Кузьминского о восстановлении через gdb
    2016-04-01 21:00 — 2016-04-02 03:00    попытки запуска, успешный запуск в recovery mode
    2016-04-02 03:00 — 2016-04-03 06:00    MySQLdump

    Почему это случилось?


    Админ не понимал как работает xtrabackup, что создается TMP-файл, который может расти.
    Не было чек-листа. Пытались сделать все, что приходило в голову, без всякого плана, потому что было уже не до этого. Я вмешивался и спрашивал почему до сих пор не готово.
    Нестандартные операции, о которых не были проинформированы сотрудники. Кто-то запустил xtrabackup, а дежурный админ считает, что это работает какая-то базовая штука и почему-то заканчивается место.


    Выводы


    • Избегать нестандартных операций.
      Если они происходят, то мы работаем только одной группой, и люди внутри группы должны знать, что именно происходит.
    • Непонятная проблема -— доложить менеджеру. Раньше, если возникала непонятная проблема на сервере, админы сами пытались с ней разобраться. Теперь, если почему-то заканчивается место, то админ должен сообщить менеджеру, что по неизвестной причине заканчивается место. Поскольку менеджер, возможно, проинформирован почему это происходит, возможно, знает, кто лучше справится с этой проблемой, или скажет, что админ может попробовать сам ее решить. Любая рискованная операция теперь требует двойного контроля: человек, который собирается что-то сделать, сначала говорит об этом, и только потом делает. Как второй пилот в самолете.

    Проблемы, связанные с нарушением отлаженного процесса


    В январе 2017 года был «кибер вторник». Это был наш второй большой косяк, не такой страшный, но тоже приятного мало.


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


    Дежурный админ в процессе утреннего и дневного тестирования сделал заметку к алертам, что страницы могут тормозить, страницы могут не отвечать, все нормально, это идет тест. И так и передал это следующей смене, которая пришла уже к вечеру «кибер вторника». В момент рассылки кэш страницы акции оказался отключен, туда повалил трафик, вечер и ночь сайт не отвечал.


    Что именно случилось?


    Весь «кибер вторник» магазин не работал.


    Интересно, что тут очень сложно кого-то обвинить. Каждый по отдельности всё сделал правильно: первый админ отметил, что алерты летят потому, что идет нагрузочное тестирование, другой админ прочитал об этом и не стал ничего чинить, когда полетели алерты. Все было правильно, все соблюли процесс, все было хорошо. Но все в итоге оказалось плохо.


    Почему это случилось и какие выводы надо сделать?


    Админы передавали сообщения друг другу. Сейчас мы делаем так, что админы передают сообщения при подтверждении менеджера. Если есть какая-то причина не реагировать на критические оповещения — требуется подтверждение менеджера. При этом дежурный менеджер подтверждает все текущие сообщения системы мониторинга при передаче админской смены.


    Ошибки процесса взаимодействия


    5 октября 2017 года – третий наш большой косяк.


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


    Что именно случилось?


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


    Когда разработчик пришел и сказал выключить модуль на продакшене, админ решил, что если разработчик так уверенно это говорит, то, видимо, он уже спросил разрешения и у менеджера, и у клиента.


    Разработчик решил, что админ — человек ответственный, можно его попросить выключить, а он спросит у менеджера и у клиента, и, если все нормально, то выключит.


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


    Почему это случилось и какие выводы надо сделать?


    Дежурный админ ожидал, что отключение согласовал разработчик, а сам разработчик думал, что отключение согласует админ.


    Любое ожидаемое действие должно быть подтверждено. Не стоит надеяться, что кто-то другой спросит. Разработчику надо было свою просьбу направить через менеджера, менеджер подтвердил бы у клиента и передал админу.


    Заключение


    Ошибки неизбежны, любой может ошибиться. У нас очень плотный поток задач, между которыми, к тому же, надо постоянно переключаться. Мы стараемся учиться на своих ошибках и ни в коем случае их не повторять.


    Большинство проблем уже случались раньше и для них есть готовые решения, но иногда происходит что-то непредвиденное. Чтобы лучше с этим справляться, в отделе поддержки мы выделили четырех тимлидов. Они давно работают, и мы знаем, что они совершают меньше ошибок. Все стандартные ситуации дежурная группа админов решает по стандартным протоколам, а если происходит что-то совсем непонятное, сообщают тимлидам, и они уже решают на ходу, вместе с клиентом.

    ITSumma
    233,00
    Собираем безумных людей и вместе спасаем интернет
    Поделиться публикацией

    Комментарии 35

      +4
      Спасибо, очень поучительный пост!
        0
        Спасибо, рассказывать о таком, конечно, очень страшно.
          +1
          Честные рассказы о том как вы факапили и исправляли ошибки делают вам большее доверие чем обычная реклама или сарафанное радио.
          Спасибо.
        0
        Статья хороший сэлф анализ, но вам не кажется что все должно быть завязано словестно на «менеджера»? Как на счет начать использоваться CMS (Change Management System), всеобщий чат это прекрастно, но не удобно для маштабных работы. Чаты целесообразно открывать для каждой работы или проекта — для общего процесса работы нужен CMS, где поднимаются плановые работы на каждый конкретный участок с отметками что должно быть сделано, будет сделано и что остается в плане. Естесветнно все это должно сопровождаться нотификацими в NOC и ответственным инженерам + Project Manager. При необходимости включается пошаговая апрув система. Если работа с клиентом ведется прозрачно — необходимо заранее добавить в ключевые нотификации SPOC (Single Point of Contact) лицо, таким образом достигается прозрачность действий для всех звений процесса. Для NOC всегда указываются время начала и время конца плановых работ, Zabbix отлично справляется с такими задачами — в этом случае не возникает необходимости переподверждать временные рамки для конкретных действий

        Для полного камильфо системы апрува привязываются к телеграмму или простым мэилам.
        Как следствие накопленную базу плановых работ применяем к:
        1. KPI для инженеров и проектов
        2. База знаний для последующих работ
        3. History лог для компаний
        4. Расчет временных рамок работ для биллинга непосредственно для каждой компании

        За статью спасибо, нравится когда люди анализируют ошибки
          0
          у нас основная работа идет в чатах, но чаты строго в телеграме и, при этом, серъезно интергрированы с системой управления проектами и мониторингом — вот здесь пишем об этом habrahabr.ru/company/itsumma/blog/335446

          спасибо за коммент, приходите к нам в uptime.community поговорить ;), можно в телеграм канале telegram.me/uptime_community
          можно в фб www.facebook.com/groups/uptime.community
          +2
          Очень интересна судьба админа из первого случая, или его «простили»?
            +1
            я бы не назвал это «простили», но если речь о штрафах/увольнениях — то нет, не штрафовали/не увольняли.
            работу над ошибками проводили плотную и со всеми.
            один раз ошибается каждый, и чаще всего — это из-за ошибок в процессах в компании
            можно было бы опасаться за то, что такое повторится, но человек опытный а работа шла в огне.
              0
              А можно было спасти админа, если бы он видел все открытые алерты по клиенту и историю работы по ним? Например, один человек проводит какие-то работы по алерту, в результате чего приходит второй алерт (кончается место). Второй человек видит алерт и факт проведения работ на сервере. Стал бы он чистить xtrabackup?
              +2

              Если бы я оказался админом из первого случая (а подобную ошибку в запарке любой может допустить), я бы и безо всяких прощений-непрощений хотел бы сделать себе харакири. :-)


              Тут важно не наказывать, а разобрать кейс и изменить процессы таким образом, чтобы подобное не повторилось.

              0
              Это все хорошо, пока в роли менеджера разбирающийся человек, который не накричит на админа, который позвонил в 3 утра со словами «Что делать?».
              Самое важное — здравый смысл, ответственность и умение думать наперед. А если у админов имеется такое качество как недоверчивость и желание перепроверить свои действия — то это замечательный администратор, на которого можно положиться.

              Но от человеческого фактора избавиться невозможно, поэтому в бюджет компании следует закладывать такие неприятности :)
                0

                А у автора статьи в фирме весь бизнес как раз построен на том что менеджер разбирается.

                  0
                  Так у них же работа круглосуточная благодаря офисам в нескольких часовых поясах. По ним разбросаны не только админы, но и менеджеры, наверно. При большом количестве проектов с регулярными звонками в 3 ночименеджеры или валить начнут, или их слишком много потребуется.
                  Вот кстати да, eapotapov, какая у вас нагрузка по часам/проектам на разный персонал, как она распределяется?
                  +1
                  А почему в первом случае (когда пришел клиент с критически важной инфой и БЕЗ БЭКАПОВ (ну вот откуда вообще такие берутся :()), сразу первым делом не сделать бы полный бэкап на уровне сервера (снять образ диска например) и потом уже спокойно ковырять скрипты? Ну и если у них до 18 нагрузка — значит договариваемся на maintenance window после 18-19 и спокойно работаем.
                    +1
                    Собственно, план и состоял в том, чтобы в первую очередь сделать бэкап и горячий резерв базы, с которого можно будет круглосуточно безболезненно снимать данные.

                    Способы снятия бэкапа, конечно же, обсуждались разные. И как в самом начале заметки говорилось, база у клиента была немаленькая, больше 2Тб. Никакого локального хранилища с толстым каналом, к сожалению, рядом не было. А на 100Мбитах тащить такой объём данных — это больше трёх суток в идеальных условиях. Т.е. «за пару часов вечером после шести» это было, увы, не решить.

                    Потому и было принято решение снимать бэкап в фоне экстрабэкапом.
                      +1
                      Если клиент близко — то можно просто приехать к нему с носителем. Если далеко — попросить его админов подключить винт к серверу. Если сервер в ДЦ — то можно и еще один сервер/хранилище арендовать на месяц там же для временного бэкапа.
                      Вероятно я не в курсе каких-то тонкостей, но вот эти мысли приходят в голову в первую очередь.
                      Ну или вы там про отсутсвие слейва говорили — а почему бы его не поднять? После 18 же можно перезапустить MySQL?
                        0
                        Ну или вы там про отсутсвие слейва говорили — а почему бы его не поднять? После 18 же можно перезапустить MySQL?

                        Перезапустить, конечно, можно. Но чтобы где-то сделать слейв, туда сначала нужно унести данные базы. А сложности с перенесением данных я уже описал в предыдущем комментарии:)
                          0
                          Насколько помню, на репликацию вроде можно и пустой MySQL завести, и база потихоньку подтянется туда. В отличие от вышеописанного переноса данных — это будет прозрачно и незаметно.
                          — Хотя нет, похоже что вру :( Данные надо.
                    +1
                    Что-то у меня не сходится…
                    А почему ibdata у процесса xtrabackup оказался помечен как deleted?
                    Ведь админ занулял только удаленные файлы.

                      0
                      Админ искал только удалённые файлы и хотел очищать только удалённые. Но на деле получилось так, что поиск по выводу lsof делался правильно, но потом некорректно передавались данные на команду очистки. Что-то типа такого было:

                      for i in 'lsof -p id_xtrabackup| grep -i dele' ; do echo ""> /proc/id-mysql/fd/$i ; done


                      И вместо id-mysql нужно было подставить айдишник экстрабекапа. Но увы.
                        0

                        Ну так это меняет дело. Я не понял этого при чтении статьи. Это меняет ситуацию с "Админ кое-чего не знал, а потому не очень виноват" на "Админ допустил явную ошибку и стопроцентно виноват". Напишите это в тексте статьи, желательно прямо приведя эту команду (пускай она приблительная), ну или сославшись на этот ваш комментарий. В тексте статьи написано:


                        Но, к сожалению, в тот момент не все наши администраторы знали, что когда 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 будет на целый экран

                      +1
                      Удалось ли после первого инцидента сохранить отношения с компанией-владельцем базы? Как вообще разруливали с ними эту ситуацию?
                        +1
                        мы, с давних пор, исходим из того, что надо быть прозрачным с клиентом.
                        с момента события сразу сообщили о том, что происходит и продолжали поддерживать связь до исправления (это каждые 10 минут в следующие два дня).
                        клиенты оказались понимающие, бэкапы с той операции стали сниматься (а до этого не снимались год или больше и предыдущие специалисты говорили, что бэкапы снять нельзя)
                        мы обсудили, что один раз накосячить можно и работу продолжили
                        спасибо клиентам, отношения сейчас очень хорошие
                          0
                          Странно, если было бы как-то иначе. Вспоминаю, что и у нас подобное было. После этого как-то сразу деньги на оборудование появилось… :)
                        +1

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

                          +1
                          > Разработчику надо было свою просьбу направить через менеджера, менеджер подтвердил бы у клиента и передал админу.

                          А менеджер — у своего менеджера? Через полгода, глядишь, можно и приступать к работе.
                            0

                            Если вы фриленсер и работаете с 5-10 постоянными клиентами то вы сам себе менеджер фактически. Вы все сами помните. Сами общаетесь с клиентами, выясняя все нюансы. Сами являетесь гарантом.


                            А теперь поднимаемся вверх и смотрим масштабы работы предприятия.


                            Вы предлагаете отдать все на откуп только одному админу? И зачем тут будент нужна фирма как таковая?

                              0
                              Это решается регламентом ответов на простые запросы, например, даётся 10 минут на реакцию, в противном случае запросить время на уточнение +30 минут, например. Если запрос, пришедший менеджеру, требует одобрения его руководства, то менеджер отправляет запрос уже описанием контекста, например. Подозреваю, что таких уровней всего 3: админы, их менеджеры (командные), старший менеджер региона.
                              0
                              В первом случае, всё-таки, надо было втыкать локальные диски в сервер и делать бэкап в туда. Вплоть до запуска второго мускула на нестандартном порту и подключения слейвом уже его.
                                0
                                А в первом случае не думали сделать снапшот диска, на котором жил MySQL что бы потом вытащить его и поднять из него бэкап. Или не было возможности?
                                  0
                                  Выше про это уже спрашивали:) Не было хранилища поблизости, на которое смогли бы за приемлемое время перенести такой объём данных. А через основной канал в 100Мбит не уложились бы ни в какой возможный даунтайм.
                                  0

                                  Всего-то надо было включить бинарный лог, а потом сделать обычный дамп с сохранением отметок из бинарного лога. Типа так:


                                  mysqldump --single-transaction --flush-logs --master-data=2 --all-databases

                                  В начале лога будет писаться что-то типа такого:


                                  -- CHANGE MASTER TO MASTER_LOG_FILE='mysqld-bin.089207', MASTER_LOG_POS=107;

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


                                  Да, конечно, всё это будет не быстро. Но наверняка.

                                    0
                                    А вы же точно понимаете, что xtrabackup именно так и работает, да? Только он, в отличие от мускульдампа не лочит базу при этом.
                                      0
                                      --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.

                                      Какие слова или фразы из этой цитаты из документации наталкивают вас на идею блокировки базы?


                                      Для первичного бэкапа на слейв есть целый набор ключей для автоматизации этого счастья.

                                        0
                                        Да, действительно, --single-transaction в первом комментарии проглядел:)

                                        Но в целом, это не отменяет того, что экстрабэкап делает, в общем-то, то же самое, только другими средствами. Ну и интересен ещё вопрос скорости выполнения на таком большом объёме данных.

                                        Это же сначала надо в дамп это всё снять, потом преобразовывать обратно уже не слейве. Всё это время на мастере должны храниться бинлоги с самого начала, чтобы можно было нормально подцепить слейв. Что в условиях ограниченного хранилища тоже вызывает сложности.

                                        В общем, «Всего-то надо было» звучит слишком оптимистично в контексте ситуации:)
                                          0

                                          Экстрабэкап может и отработал быстрее (только не отработал!), но в отличии от него обычный дамп не вызвал бы никаких вопросов у пришедшего по тревоге администратора. Ему из вывода ps сразу всё было бы ясно и понятно. Делается бэкап.


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

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое