«Происшествие с Gitlab — очень хорошая и показательная история», — Алексей Лесовский об администрировании PostgreSQL

в 11:05, , рубрики: administration, dba, devops, linux, performance, postgresql, Администрирование баз данных, Блог компании PG Day'17 Russia, Серверное администрирование, хранилища данных

Друзья, сегодняшняя публикация открывает новую рубрику в блоге конференции PG Day Russia: интервью со специалистами в области эксплуатации баз данных. Беседа с профессионалом — отличная возможность приоткрыть завесу тайны, узнать секреты профессии, выяснить чем и как зарабатывают коллеги, посвятившие свою жизнь работе с СУБД. Мы надеемся, что предстоящие выпуски помогут вам взглянуть на рабочий процесс с новой стороны, дадут возможность задать волнующий вас вопрос, получить совет или же сориентироваться в дальнейших шагах по собственной карьерной лестнице.

В нашем пилотном интервью мы поговорили с Алексеем Лесовским, DBA компании Data Egret (бывш. PostgreSQL-Consulting). Алексей является специалистом с многолетним стажем в области администрирования PostgreSQL. Регулярные посетители технических конференций знают не по наслышке, что его доклады и мастер-классы славятся глубиной проработки и вниманием к деталям.

PG Day: Леша, давай начнем с вводной информации. Расскажи в двух словах про себя, как ты решил стать DBA и как ты вообще до такой жизни, что называется, докатился.

АЛ: Вообще, идеи стать DBA изначально у меня не было. Я к этому не стремился. Я работал системным администратором в компании, которая занималась веб проектами, администрировал линуксовые сервера, занимался виртуализацией. Весь их стек был построен на современных технологиях. Там были рельсы, там были мемкэши, редисы и был Postgres.

«Происшествие с Gitlab — очень хорошая и показательная история», — Алексей Лесовский об администрировании PostgreSQL - 1

Команде в какой-то момент надоела возня вокруг MySQL, и они решили имеющиеся проекты перевести на Postgres.Так что я администрировал там и Postgres. Сначала это были задачки из серии что-то посмотреть, добавить, поменять права, раскатать staging для девелоперов. Постепенно круг задач расширялся. Мы с коллегами проводили апгрейды с мажорных версий и делали это довольно неординарно, не по официальной документации. Прибегали ко всяким интересным инструментам. В итоге, я увлекся базами данных, увлекся Postgres.

Потом я устроился работать в другую компанию, где и познакомился с будущими коллегами из сферы консалтинга (Data Egret — прим. ред.), они работали в качестве отдельных DBA. Мы подружились и я ушел к ним работать и стал уже полноценно заниматься администрированием Postgres, администрированием баз данных. И вот больше линуксом практически не занимаюсь. Администрированием я уже давно плотно не занимался. Но с линуксом и с PostgreSQL по-прежнему работаю.

PG Day: Несмотря на то, что ты не занимаешься администрированием линукса, у тебя все равно опыт очень обширный, и ты много об этом рассказываешь. Я думаю, что всем будет интересно, как ты узнаешь какие-то новые вещи про линукс, что ты для этого используешь? Как поддерживаешь свой уровень квалификации?

АЛ: В первую очередь, это LWN рассылка. Там очень много анонсов, что происходит в самом Linux’е, в его ядре, какие изменения и новшества — очень классный ресурс. Помимо этого, я читаю PostgreSQL Planet – это такой агрегатор блогов, посвященный PostgreSQL, содержит много блогов и новые статьи выходят очень часто. Есть еще очень хороший ресурс http://highscalability.com, он посвящен производительности: как большие компании решают свои проблемы связанные с ИТ. Очень познавательный блог.

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

PG Day: Раз мы уж говорим про Linux, какими инструментами ты пользуешься для своей ежедневной работы с Linux’ом? Что ты считаешь, в первую очередь, самым важным?

АЛ: Дома на рабочем компьютере у меня стоит Gentoo Linux, я давно использую этот дистрибутив, считаю его достаточно надежным и стабильным. Рабочее окружение – KDE, терминал – yakuake, очень удобная Quake-подобная консоль, которая появляется по хоткею. Дальше все более-менее стандартно – Chrome, Skype, Slack, Telegram, Libre Fffice, vim. Еще есть оффлайновая программа для ведения заметок – Keepnote, в ней я веду заметки, базу знаний, todo-списки. Раньше была еще более клевая Mytetra, но в ней начали пропадать заметки, были проблемы с запуском, и я ушел с нее. А если случается командировка, беру ноутбук с Windows, на котором стоит почти все тоже самое. Вобщем никакой экзотики.

Самым важным, я, конечно же, считаю наличие интернета, учитывая, что я работаю из дома и имею возможность работать с любой точки планеты, мне важно чтобы был интернет. Также важно наличие SSH клиента, SSH это такой протокол для работы с удаленными Linux серверами и вообще, везде, где есть SSH демон. Вобщем самое важное это интернет и SSH-клиент. И если я работаю на рабочей станции Windows, мне достаточно Putty. Я подключаюсь к серверам, мне достаточно обычной текстовой консоли, которую предоставляет SSH, и командная оболочка. Там я уже работаю с самими серверами и использую утилиты.

Какие утилиты я использую на серверах? Это стандартный набор администратора, довольно-таки простой. Команда top, команды из пакета sysstat. Если нужно что-то посмотреть более специфическое, связанное с оборудованием или с драйверами, то в ход идут утилиты, которые предназначены для конкретного оборудования.

Но основная утилита, это, конечно же, top. С нее все всегда начинается. Если нужно что-то посмотреть, определить, куда дальше копать, я открываю top, смотрю, планирую куда двигаться дальше.

PG Day:В принципе, у тебя в работе обычно инструменты достаточно бытовые и стандартные. Но бывали ли случаи, когда приходилось закапываться очень глубоко, использовать какие-то нетривиальные решения? Может быть, даже патчи писать какие-то? Сталкивался ли с такими ситуациями в своей практике?

АЛ: Сразу скажу, патчи писать не приходилось, и в будущем не сильно планирую, потому что это очень длинный workflow. На эту тему есть очень много инструкций, как стать разработчиком линуксового ядра или Postgres’а, как оформлять, отправлять, принимать патчи, как взаимодействовать с сообществом.

Но, тем не менее, сложные и изначально непонятные проблемы периодически встречаются, и есть инструменты, с помощью которых можно копать. Инструменты, как правило, тоже довольно специфичные. У них километровые страницы документации и поначалу очень сложно ими пользоваться, особенно новичкам. Но, тем не менее, когда часто ими пользуешься, постепенно приходит понимание, какие ключи и когда использовать. В основном, это утилиты strace и ltrace, если у нас программа падает с какой-то ошибкой или segfault происходит, либо какое-то ненормальное поведение, которое завершает работу программы. Что делают эти утилиты? Они позволяют отслеживать, какие системные и библиотечные вызовы выполняет программа во время своей работы. Очень часто их приходится комбинировать со средствами командной строки, например запускать в циклах или только при наступлении определенных условий.

Другая утилита из такой же серии – это perf. Это такой мощный молоток, который позволяет очень глубоко закапываться в то, чем занимается программа. Я запускаю perf, указываю параметры для анализ и трассировки. Программа собирает информацию. У нее получается на выходе файл, который дальше либо анализируется с помощью того же самого perf либо других вспомогательных скриптов. Но у этих программ довольно высокий порог вхождения и можно пользоваться обычными примерами, которые приведены в документации. Но постепенно нужно разбираться, что можно исследовать этими программами и как-то на боевых нагрузках проверять, тестировать, смотреть. Для этого нужен опыт и практика.

PG Day: В последнее время ты начал очень много читать лекций, мастер-классов, тренингов. Расскажи о своих впечатлениях от этого опыта. Чем интересуются люди, которые приходят на твои выступления? что тебе нравится при работе с аудиторией?

АЛ: Да, верно подмечено, я читаю лекции, доклады, выступаю с мастер-классами, занимаюсь этим уже два года. Начинал я в 2014. Мне нравится рассказывать о том, какой у меня опыт, какие у меня практические сценарии, кейсы были в работе, и это главное. Нельзя рассказывать доклады и мастер-классы, если из-под палки этим приходится заниматься.

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

PG Day: Летом 2017 года ты планируешь давать еще один большой мастер-класс на предстоящем PG Day. Я думаю, слушателям будет интересно узнать, что их ждет на этом мастер-классе, что ты поведаешь, о каких проблемах будешь рассказывать, кому это может быть интересно?

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

Я буду рассказывать о практических инструментах, с минимумом теории. Как запускать утилиты и инструменты, какие настройки влияют на работу операционной системы и Postgres. Почему нужно их настраивать?

Основная фишка, которая планируется для мастер класса — это сервер, на котором можно будет все эти приемы продемонстрировать. На этом сервере я смоделирую сценарии поведения неправильной работы Postgres, операционной системы, и мы сможем их с участниками “траблшутить”, смотреть метрики, предпринимать какие-то действия, пытаться решить эти проблемы. В ходе этого мастер класса я покажу все свои основные методы траблшутинга и постараюсь донести людям, как это нужно делать с Postgres. Я надеюсь, что участники смогут перенять часть моего опыта.

PG Day: Я заметил, что собираешься уделить внимание вопросу подбора оборудования. Откуда возникла необходимость тщательно подбирать оборудование для работы с базой, с Postgres в частности?

АЛ: Я решил захватить этот момент, потому что мы выбираем операционную систему, на которой будет работать Postgres, а операционная система будет работать на каком-то железе. Соответственно, вопрос выбора железа тоже зачастую встает. В мастер-классе я часть времени уделю подбору железа, какие серверы выбирать и как их настроить. Workflow на сервере может быть самый разный: веб-серверы, виртуализация, базы данных. Некоторые настройки, например виртуализация для баз данных просто не нужны. Их можно выключить и чуть-чуть сэкономить на производительности. В мастер-классе я об этом расскажу.

«Происшествие с Gitlab — очень хорошая и показательная история», — Алексей Лесовский об администрировании PostgreSQL - 2PG Day: Не удержусь и задам один вопрос про файловые системы. На какую конференцию не приеду, баталии ожесточенные, какую выбрать файловую систему под базы данных, и чем они лучше. Чем будет отличаться твой рассказ от этих традиционных битв “файловая система №1 против файловой системы №2”?

АЛ: На самом деле, мы живем в 2017 году, вопрос выбора файловых систем уже решился лет пять назад а то и еще раньше. Сейчас для баз данных есть две файловые системы. Это ext4 и xfs. Обе файловые системы дают примерно одинаковые результаты в любых тестах и довольно стабильны в работе. В них практически уже не находят никаких багов. Работают они стабильно и хорошо. Поэтому в моем мастер-классе не будет никаких сравнений, тезис довольно простой: используйте xfs, либо используйте ext4, и все.

Не нужно метаться между экзотическими файловыми системами типа btrfs, zfs on Linux или, не дай Бог, ReiserFS. Лично же я, предпочитаю ext4, потому что там есть такая шутка как зарезервированное место для файлов пользователя root, 5% выделяется. Эта штука очень полезна и очень часто выручала, когда место на диске быстро заканчивается. Этот резерв можно уменьшить и в файловой системе появляется много свободного места. В xfs тоже есть такая штука, но она как-то хитро закопана и неочевидно работает. И по-умолчанию там совсем небольшой резерв. Так что на данный момент ext4 мне нравится больше.

PG Day: В заключение задам пару вопросов, которые были пожеланиями от слушателей. Первый вопрос про нашумевшую историю с Gitlab. Очень много было споров на тему того, накосячили они или нет. Что ты по существу можешь сказать по этому вопросу? Как такие проблемы избегать и что они сделали не так?

АЛ: На самом деле, это очень хорошая и показательная история. У них базой данных занимался мастер на все руки. Из этой всей истории мне показалось, что у него недостаточно знаний, как работать с PostgreSQL, несмотря на то, что у Посгреса очень большая и развёрнутая документация. Он обнаружил, что между мастером и репликой есть отставание, так называемый лаг. И он решил перезалить реплику. Это неправильно. На самом деле, действовать надо было совсем иначе. И второй момент – это невнимательность, отсутствие наработанных процедур. В серьезных компаниях всегда есть инструкции, как и что делать в аварийных ситуациях. Все switchover-ы прописаны с таким уровнем детализации, который не подразумевает никакой двусмысленности. Все команды прописаны, все решения, ответвления да/нет.

В случае возникновения такой ситуации человек, дежурный инженер или дежурный администратор, который есть на месте, достает эту инструкцию и по инструкции все делают. Отсутствие этих инструкций сыграло злую шутку. Поэтому пришлось восстанавливать, импровизировать на ходу, что-то там делать, писать в твиттер. Всем было интересно за этим наблюдать. Люди повеселились. Тем не менее, за то, что человек совершил ошибку, как мне показалось, никаких крайне жестких мер там не было принято. С одной стороны это хорошо, так как к сожалению, все совершают ошибки. И я тоже совершаю ошибки. С другой стороны главное учиться на своих ошибках и не повторять их.

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

АЛ: На самом деле, каких-то устоявшихся или часто встречающихся граблей я не припомню. Ситуации всегда бывают разные, написать инструкции на все ситуации невозможно. Надо отталкиваться от рисков, которые есть в инфраструктуре или в той же базе данных. Есть риск потери данных, есть риск потерять доступность к базе данных. Эти риски и их можно просчитать. Можно на них написать основные инструкции и ими пользоваться.

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

Что можно посоветовать людям? Будьте внимательны к мелочам, смотрите в какой консоли вы находитесь, старайтесь документировать все неприятные и новые истории, которые с вами случались — получится неплохой knowledge base. Из этих историй всегда можно сделать какие-то выводы, чтобы эти истории не повторялись в будущем. Самое основное – это быть внимательным и, конечно же, изучать то, с чем вы работаете. Если вы работаете с Postgres, изучайте Postgres, работаете с Ruby – изучайте ruby. Уделяйте время самообразованию.

Подписывайтесь на рассылки новостей, которые связаны и с Постгресом, и вообще с базами данных. Такие рассылки позволяют следить за трендами, за тем что происходит сейчас в сфере СУБД. Из этих же рассылок можно взять ссылки на полезные блоги, и читать их между рассылками. Еще обязательно нужны фундаментальные знания, связанные с устройством СУБД. Есть интересные книги про теорию устройства транзакционных движков, журналов транзакций и много другого (Stonebraker, Weikum & Vossen, etc.)

Надеемся, что интервью с Алексеем было для вас интересным. Мы рады пригласить всех в Санкт-Петербург на нашу конференцию PG Day'17 Russia, в рамках которой Алексей проведет интенсивный тренинг Call of Postgres: Advanced Operations, в котором собрана многочисленная информация о том, как настраивать PostgreSQL и оборудование вместе с операционной системой Linux для оптимальной работы. Будут рассмотрены многочисленные компоненты и их настройка. Отдельно будут изучены методы диагностики и устранения неполадок в операционной системе и в самом Постгресе.

До встречи на PG Day'17 Russia!

Автор: rdruzyagin

Источник

Поделиться

* - обязательные к заполнению поля