Базы данных *

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

Подобно им, администраторы БД также делятся на две категории, те, кто уже запускал процедуру удаления на большой БД с типом таблиц InnoDB, и те, кому это ещё предстоит.



Разумеется, в теории все знают, что из-за особенностей InnoDB, удаление может быть долгим, но это знание сродни тому, что «надо делать бэкапы». Многие осознают эти нехитрые истины, только наступив на грабли.

Для понимания, удаление 350М записей в таблице на 500М записей может занять более двух суток. Вторые грабли, на которые многие наступают, это попытка прибить запрос. Как мы все помним, InnoDB движок транзакционный, поэтому если вы попытаетесь прибить запрос, он попытается откатить изменения, а это может занять больше времени, чем выполнялся запрос.

Как сделать так, чтобы не было мучительно больно? Добро пожаловать под кат!

Добрый день! Данная статья является продолжением статьи "Дружим Prometheus с Caché". Мы рассмотрим вариант визуализации результатов работы утилиты ^mgstat. Эта утилита предоставляет статистику производительности Caché, а именно, число вызовов глобалов и рутин, локальное и по ECP, длину очереди демона записи, число блоков, записанных на диск и считанных с диска, объем ECP-трафика и прочее. Запускаться ^mgstat может как отдельно (интерактивно или джобом), так и при работе другой утилиты оценки производительности ^pButtons.

Изложение материала хотелось бы разбить на две части: в первой графически показать непосредственно статистику, собираемую ^mgstat, а во второй — рассмотреть, как именно эта статистика собирается. Если коротко, то используются $zu-функции. Однако к большинству собираемых параметров есть и объектный интерфейс через классы пакета SYS.Stats. И далеко не все параметры, которые можно собрать, показываются в ^mgstat. В дальнейшем мы попробуем все их отобразить на Grafana-дашбоардах. В этот же раз покажем только то, что нам предоставляет сам ^mgstat. Кроме того, попробуем на вкус Docker-контейнеры.

Совсем недавно мы опубликовали первую часть интервью с ведущими специалистами из компаний РТ ЛАБС, Git in Sky, Postgres Professional, Avito и EnterpriseDB. Если сейчас вы решаете, стоит ли связывать свою жизнь с профессией DBA, то вам придется очень кстати вторая часть советов от спикеров PG Day’16. А если вопросы еще останутся, то вы можете задать их докладчикам текущего года с 5 по 7 июля на PG Day’17 Russia.

Сегодняшнее интервью дает Илья Космодемьянский, CEO Data Egret, ведущего PostgreSQL-консалтинга, и сооснователь PG Day Russia. За 15 лет работы Илья прошел путь от разработчика и DBA до руководителя собственной компании, оказывающей услуги поддержки баз данных. Сегодня Илья занимается формированием и реализацией стратегии развития Data Egret, продвигает бренд компании в российском и международном сообществе, курирует направление подбора докладчиков для конференции.

На PG Day'17 Russia Илья проведет интенсивный учебный курс по PostgreSQL для системных администраторов и DevOps.

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



PG Day: Компания, которую ты основал, предоставляет поддержку для PostgreSQL. Почему именно PostgreSQL, а не MS SQL Server или ORACLE?

Илья: Поскольку мы начали заниматься Postgres-ом, до того как это стало модно, можно честно сказать, что это был осознанный выбор. Сейчас о Postgres-е не говорит только ленивый, а в те времена это была хорошая open source-ная база, но не более того.

Сегодня мобильный телефон — ключевой идентификатор личности, а количество мобильных устройств превысило население планеты. Это основной способ связи с человеком и главный канал для доставки информации.

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

Прошу, не путайте сжатие журнала транзакций со сжатием файлов данных. Сжатие журнала необходимо, если ваш журнал вырос сверх допустимых пределов, или при избавлении от избыточной фрагментации виртуальных файлов журнала (смотрите здесь (английский) и здесь (английский) замечательные статьи Кимберли). Тем не менее, сжатие журнала транзакций должно быть редкой операцией и никогда не должно входить ни в одну регулярную программу обслуживания, которую вы выполняете.

Сжатие файлов данных должно выполняться еще реже, если должно вообще. И вот почему — сжатие файлов данных вызывает серьезнейшую фрагментацию индексов. Позвольте мне продемонстрировать это на простом скрипте, который вы можете выполнить сами. Скрипт ниже создаст файл данных, создаст таблицу-«наполнитель» размером 10Мб в начале файла данных, создаст «производственный» кластерный индекс размером 10Мб, и потом проанализирует фрагментацию нового кластерного индекса.

Нам попадалось множество историй о том, как эксплойты наносили непоправимый урон сообществам или вообще приводили их к краху. Начиная работу над проектом Discourse, мы помнили об уроках, которые извлекли из этих историй. Мы поставили перед собой цель создать программу с открытым кодом, которая по умолчанию обеспечивала бы безопасность всем своим сообществам — пусть даже их будет тысячи или миллионы.


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

Владельцы форумов имеют возможность создавать бэкапы и восстанавливать целые базы данных сайтов прямо из администраторской панели в веб-браузере. Автоматические бэкапы по умолчанию производятся на еженедельной основе. Я же не просто так считаюсь ведущим мировым экспертом по бэкапам!

Беда пришла откуда не ждали… У клиента завис процесс “Касса”, так что не смог снять процесс через Диспетчер задач. Рабочее место “Касса” — одновременно сервер всей системы.

Клиент принял решение ресетнуть через кнопку.

В итоге умерла DB. FireBird 2.5

SQLskills запускает новую инициативу по размещению записей с базовыми знаниями, мы назвали ее SQL101. Мы будем писать о вещах, которые, как мы часто видим, делаются неправильно, технологиях, которые используются неверно, и о многих недопониманиях, которые приводят к серьезным проблемам. Если вы хотите найти все записи в этой серии, проверьте ссылку SQLskills.com/help/SQL101 (английский).

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

Нравится нам это или нет, но нереляционные базы данных с открытым исходным кодом составляют значительную часть сложившейся экосистемы инструментов для хранения данных, повсеместно применяются как в небольших, так и крупных Web-проектах. Вполне вероятно, что кому-то из вас пришлось столкнуться с MongoDB в «продакшене». Умение обезопасить БД от внешних посягательств является необходимым для успешной экплуатации навыком. Об этом и многих других вопросах мы поговорим на PG Day'17 в секции открытых баз данных. Тем временем, мы рады представить вам перевод интересной обзорной публикации, посвященной безопасности MongoDB.



У MongoDB есть всё необходимое для сохранения ваших данных в целости. Мы расскажем о том, что именно может вам понадобиться и как это настраивать.

Безопасность MongoDB снова в новостях. Совсем недавно СМИ наводнили истории, рассказывающие о том, как хакеры захватывали базы данных MongoDB и требовали выкуп в биткойнах. Десятки тысяч инсталляций MongoDB были скомпрометированы, согласно Rapid7.

Одним из самых популярных докладов конференции PG Day в 2015 году стал рассказ Владимира Бородина и Ильдуса Курбангалиева о ситуациях, когда посгресовым базам становится плохо, надо их диагностировать и искать узкие места. Все примеры в докладе взяты из реальной практики Яндекса, сопровождаются иллюстрациями и подробным рассказом о поиске «боттлнека». Не смотря на то, что проблемы рассматривались в разрезе 9.4 и 9.5 версий базы данных, общая ценность и практическая применимость советов Владимира и Ильдуса остается неизменной. Рады предложить вам транскрипцию этого доклада.

Вступление Ильи Космодемьянского: сейчас у нас будет рассказ о том, как жить, если очень хочется иметь Oracle, а его нет. На самом деле, это полезный доклад, потому что одна из проблем, которую мы сейчас имеем – это проблема средств диагностики. Средства диагностики местами не достают, местами, вместо привычных средств диагностики нужно использовать довольно сложные тулзы, которые вообще предназначены для разработчиков Linux, а не для DBA. У DBA зубы начинают болеть, когда они смотрят на эти скрипты. И вот ребята из Яндекса и PG Pro расскажут о методах диагностики Postgres, которые они применяют, как ими пользоваться и немного расскажут о том, как они собираются улучшить этот мир.

31 января 2017 года у GitLab случилась авария, связанная с эксплуатацией СУБД PostgreSQL, в результате которой часть данных была удалена, а проект был остановлен на время восстановления. Прошло уже несколько месяцев, и было очень много написано на эту тему, а сам GitLab представил исчерпывающий некролог, в котором рассказал, что произошло, какие предпринимались меры для восстановления и какие меры будут предприняты для предотвращения подобных аварий. Очень занимательное чтиво, рекомендуем его прочесть даже тем, кто далек от Постгреса.



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

Может ли Pilot-ICE спасти данные от вирусов-шифровальщиков? Чтобы ответить на этот вопрос, мы провели экспериментальное заражение нашумевшим вирусом Wana Decrypt0r 2.0 изолированной тестовой системы, на которой запущен сервер Pilot-Server и клиент Pilot-ICE. Другие криптовирусы действуют по схожему принципу, отличается только способ заражения. Рассматриваем самый экстремальный случай, когда резервной копии нет.



Рассказывает Дмитрий Поскребышев — руководитель отдела разработки систем управления инженерными данными.

Приветствую уважаемое Хабросообщество! Как известно у сервера MySql нет встроенных механизмов для переноса пользователей MySql и их привилегий на другой сервер. В сети готовых решений крайне мало, и в этой небольшой статье мы перенесем наших пользователей MySql и их привилегии, с одного сервера на другой, за несколько минут.

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

В феврале этого года Света Смирнова (ведущий инженер компании Percona) провела вебинар, посвященный решению проблем с правами доступа в MySQL. Запись и слайды с вебинара доступны здесь. Предлагаем вашему вниманию небольшой обзор самых популярных вопросов на эту тему.

В первой части статьи «Ускоряем восстановление бэкапов в Postgres» я рассказал о предпринятых шагах по уменьшению времени восстановления в локальном окружении. Мы начали с простого: pg_dump-пили (а есть ли такое слово?), паковали gzip-ом, распаковывали и направляли вывод в psql < file.sql. На восстановление уходило около 30 минут. В итоге мы остановились на настраиваемом (custom) формате Postgres и применили аргумент -j, добившись уменьшения времени до 16 минут.

В этой статье я описал, как нам удалось уменьшить размер файла резервной копии, что дополнительно ускорило процедуру восстановления.

Мои ощущения от процесса работы

Недавно я решил заняться ускорением восстановления нашей базы данных в dev-окружении. Как и во многих других проектах, база вначале была небольшой, но со временем значительно выросла. Когда мы начинали, ее размер было всего несколько мегабайт. Теперь упакованная база занимает почти 2 ГБ (несжатая — 30 ГБ ). Мы восстанавливаем dev-окружение в среднем раз в неделю. Старый способ проведения операции перестал нас устраивать, а вовремя подвернувшаяся в Slack-канале картинка “DB restore foos?” побудила меня к действию.

Ниже описано, как я ускорял операцию восстановления базы данных.

Нынче в каждой приличной организации, разрабатывающей серьезное программное обеспечение, принято делиться, какими путями создавались и развивались ее проекты. Мы считаем это отличной тенденцией и готовы поведать свой вариант развития одного из внутренних проектов компании «СБИС». Он влияет самым серьезнейшим образом на все ее остальные продукты, и его ласково называют — «Хоттабыч», ибо делает волшебство!

Каждые 100 секунд он обновляет какое-нибудь приложение в боевом или в тестовом окружении. Приложений у нас только в «продакшн» около 200, а на тестовых стендах — больше 1000. Количество виртуальных серверов, на которых развернуто каждое приложение – от двух до нескольких сотен. Итак, по порядку…

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

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

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

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

Предисловие от переводчика: CockroachDB — достаточно молодая реляционная СУБД с открытым кодом (лицензия Apache 2.0), изначально созданная быть распределённой (с горизонтальным масштабированием «из коробки») и отказоустойчивой. Её авторы из компании Cockroach Labs, созданной в 2015 году, задаются целью «совместить богатство функциональности SQL с горизонтальной доступностью, привычной для NoSQL-решений». Данное руководство написано одним из сотрудников компании-разработчика и опубликовано на сайте облачного провайдера DigitalOcean для того, чтобы познакомить ИТ-специалистов с этой СУБД и продемонстрировать её использование.

Введение

CockroachDB — распределённая СУБД (SQL) с открытым кодом, обеспечивающая согласованность данных, масштабируемость и выживаемость.

Настройка CockroachDB проста: устанавливаете её на нескольких серверах (узлах) и объединяете их в единое целое для совместной работы (кластер). Все узлы кластера действуют «симметрично» и предлагают доступ к одинаковым данным. Если хранилище для данных необходимо увеличить, то при используемой архитектуре достаточно создать новые узлы и присоединить к кластеру.