Я занимаюсь АТСками. И как-то так сложилась, что с самого первого заказа от меня хотели отказоустойчивости. Одним из ключевых компонентов современной АТС (как и любой информационной системы, наверное) является БД, где хранятся как данные о текущем состоянии системы, так и всякие конфигурационные параметры. Естественно, падение БД приводит к поломке всей системы. Начиналось все с MASTER-MASTER репликации в MySQL (исключительно для оперативности переключения), потом были эксперименты с MySQL over DRBD. Все это жило в pacemaker/corosync инфраструктуре. Там ездили IP-адреса, шлюзы и прочая лабудень. Со временем оно даже стало работать как-то более-менее устойчиво. Но тут мне попалась пара серверов, на которых DRBD сделать было нельзя, в MASTER-MASTER я разочаровался довольно давно (постоянно она у меня ломается, такая репликация), а без отказоустойчивой БД терялся весь смысл решения. На глаза мне попалось название InnoDB cluster и я решил: "была-не-была". Что из этого получилось — смотрите под катом.
Рубрика «Администрирование баз данных» - 38
InnoDB cluster — оно работает, и вроде бы именно так, как обещали
2017-07-06 в 0:13, admin, рубрики: clusterization, innodb, mysql, Администрирование баз данных, базы данных, хранилища данныхКак быстро удалить множество строк из большой базы в MySQL
2017-07-03 в 11:25, admin, рубрики: innodb, mysql, Администрирование баз данных, системное администрированиеКак известно, все системные администраторы делятся на две категории. Те, кто уже делают бэкапы и те, кто ещё нет.
Подобно им, администраторы БД также делятся на две категории, те, кто уже запускал процедуру удаления на большой БД с типом таблиц InnoDB, и те, кому это ещё предстоит.
Разумеется, в теории все знают, что из-за особенностей InnoDB, удаление может быть долгим, но это знание сродни тому, что «надо делать бэкапы». Многие осознают эти нехитрые истины, только наступив на грабли.
Для понимания, удаление 350М записей в таблице на 500М записей может занять более двух суток. Вторые грабли, на которые многие наступают, это попытка прибить запрос. Как мы все помним, InnoDB движок транзакционный, поэтому если вы попытаетесь прибить запрос, он попытается откатить изменения, а это может занять больше времени, чем выполнялся запрос.
Как сделать так, чтобы не было мучительно больно? Добро пожаловать под кат!
Читать полностью »
GUI на Grafana для mgstat — утилиты мониторинга системы на InterSystems Caché, Ensemble или HealthShare
2017-06-29 в 4:38, admin, рубрики: Администрирование баз данных, Блог компании InterSystemsДобрый день! Данная статья является продолжением статьи "Дружим Prometheus с Caché". Мы рассмотрим вариант визуализации результатов работы утилиты ^mgstat. Эта утилита предоставляет статистику производительности Caché, а именно, число вызовов глобалов и рутин, локальное и по ECP, длину очереди демона записи, число блоков, записанных на диск и считанных с диска, объем ECP-трафика и прочее. Запускаться ^mgstat может как отдельно (интерактивно или джобом), так и при работе другой утилиты оценки производительности ^pButtons.
Изложение материала хотелось бы разбить на две части: в первой графически показать непосредственно статистику, собираемую ^mgstat, а во второй — рассмотреть, как именно эта статистика собирается. Если коротко, то используются $zu-функции. Однако к большинству собираемых параметров есть и объектный интерфейс через классы пакета SYS.Stats. И далеко не все параметры, которые можно собрать, показываются в ^mgstat. В дальнейшем мы попробуем все их отобразить на Grafana-дашбоардах. В этот же раз покажем только то, что нам предоставляет сам ^mgstat. Кроме того, попробуем на вкус Docker-контейнеры.
Spark-in.me. Часть 4 — Базовое админство для обычных человеков
2017-06-26 в 4:01, admin, рубрики: postgresql, tar, администрирование, Администрирование баз данных, бекапы, Восстановление данных, Серверное администрирование
У слова backup есть несколько значений, как и у других похожих слов, например setup — это еще и «прикид», а не только набор настроек, устройств и еще бог весть чего.
- Spark-in.me. Часть 1 — Зачем и почему?
- Spark-in.me. Часть 2 — Архитектура приложения и структура БД
- Spark-in.me. Часть 3 — DIY поддержка и админство сайта
- Spark-in.me. Часть 4 — Базовое админство для обычных человеков
- Spark-in.me. Часть 5 — Переход на HTTPS
- Spark-in.me. Часть 6 — Исходный код и настройка бекенда
- Spark-in.me. Часть 7 — Исходный код и настройка фронтенда
«Когда с базами данных происходит критическая авария, это всегда случается несколько эпически» — Илья Космодемьянский
2017-06-15 в 9:23, admin, рубрики: data egret, interview, postgresql, postgresql consulting, Администрирование баз данных, Блог компании 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-ная база, но не более того.
Читать полностью »
Почему вы не должны сжимать ваши файлы данных
2017-06-08 в 8:53, admin, рубрики: dbcc shrinkdatabase, dbcc shrinkfile, Microsoft SQL Server, shrink, sql server, Администрирование баз данных, сжатиеОдна из самых моих горячих проблем касается сжатия файлов данных. Несмотря на то, что я владел кодом сжатия, когда работал в Майкрософт, у меня не было шанса переписать его так, чтобы сделать его более приятным. Мне действительно не нравится сжатие.
Прошу, не путайте сжатие журнала транзакций со сжатием файлов данных. Сжатие журнала необходимо, если ваш журнал вырос сверх допустимых пределов, или при избавлении от избыточной фрагментации виртуальных файлов журнала (смотрите здесь (английский) и здесь (английский) замечательные статьи Кимберли). Тем не менее, сжатие журнала транзакций должно быть редкой операцией и никогда не должно входить ни в одну регулярную программу обслуживания, которую вы выполняете.
Сжатие файлов данных должно выполняться еще реже, если должно вообще. И вот почему — сжатие файлов данных вызывает серьезнейшую фрагментацию индексов. Позвольте мне продемонстрировать это на простом скрипте, который вы можете выполнить сами. Скрипт ниже создаст файл данных, создаст таблицу-«наполнитель» размером 10Мб в начале файла данных, создаст «производственный» кластерный индекс размером 10Мб, и потом проанализирует фрагментацию нового кластерного индекса.
Читать полностью »
Как я делаю бекапы. СУБД FireBird
2017-05-31 в 13:08, admin, рубрики: backup, Delphi, firebird, inno setup, windows, Администрирование баз данных, резервное копирование, СУБД, хранение данных
Беда пришла откуда не ждали… У клиента завис процесс “Касса”, так что не смог снять процесс через Диспетчер задач. Рабочее место “Касса” — одновременно сервер всей системы.
Клиент принял решение ресетнуть через кнопку.
В итоге умерла DB. FireBird 2.5
Читать полностью »
SQL101: Почему восстановление из резервной копии медленнее, чем ее создание
2017-05-30 в 13:50, admin, рубрики: backup, Microsoft SQL Server, restore, sql server, Администрирование баз данных, восстановление, резервные копииSQLskills запускает новую инициативу по размещению записей с базовыми знаниями, мы назвали ее SQL101. Мы будем писать о вещах, которые, как мы часто видим, делаются неправильно, технологиях, которые используются неверно, и о многих недопониманиях, которые приводят к серьезным проблемам. Если вы хотите найти все записи в этой серии, проверьте ссылку SQLskills.com/help/SQL101 (английский).
Один из вопросов, который мне постоянно задают, это почему восстановление базы данных из полной резервной копии занимает больше времени, чем создание полной резервной копии. Ответ заключается в том, что почти всегда процесс восстановления требует выполнения большей работы.
Читать полностью »
Способы диагностики PostgreSQL — Владимир Бородин и Ильдус Курбангалиев
2017-05-22 в 16:34, admin, рубрики: debugging, gdb, optimization, perf, performance, postgresql, troubleshooting, Администрирование баз данных, Блог компании PG Day'17 Russia, Серверное администрирование, хранилища данныхОдним из самых популярных докладов конференции PG Day в 2015 году стал рассказ Владимира Бородина и Ильдуса Курбангалиева о ситуациях, когда посгресовым базам становится плохо, надо их диагностировать и искать узкие места. Все примеры в докладе взяты из реальной практики Яндекса, сопровождаются иллюстрациями и подробным рассказом о поиске «боттлнека». Не смотря на то, что проблемы рассматривались в разрезе 9.4 и 9.5 версий базы данных, общая ценность и практическая применимость советов Владимира и Ильдуса остается неизменной. Рады предложить вам транскрипцию этого доклада.
Вступление Ильи Космодемьянского: сейчас у нас будет рассказ о том, как жить, если очень хочется иметь Oracle, а его нет. На самом деле, это полезный доклад, потому что одна из проблем, которую мы сейчас имеем – это проблема средств диагностики. Средства диагностики местами не достают, местами, вместо привычных средств диагностики нужно использовать довольно сложные тулзы, которые вообще предназначены для разработчиков Linux, а не для DBA. У DBA зубы начинают болеть, когда они смотрят на эти скрипты. И вот ребята из Яндекса и PG Pro расскажут о методах диагностики Postgres, которые они применяют, как ими пользоваться и немного расскажут о том, как они собираются улучшить этот мир.
GitLab PostgreSQL postmortem
2017-05-18 в 11:14, admin, рубрики: backup & recovery, disaster recovery, gitlab, postgresql, Администрирование баз данных, Блог компании PG Day'17 Russia, резервное копирование, Серверное администрирование, хранение данных31 января 2017 года у GitLab случилась авария, связанная с эксплуатацией СУБД PostgreSQL, в результате которой часть данных была удалена, а проект был остановлен на время восстановления. Прошло уже несколько месяцев, и было очень много написано на эту тему, а сам GitLab представил исчерпывающий некролог, в котором рассказал, что произошло, какие предпринимались меры для восстановления и какие меры будут предприняты для предотвращения подобных аварий. Очень занимательное чтиво, рекомендуем его прочесть даже тем, кто далек от Постгреса.
В комментариях к нашему интервью с Алексеем Лесовским, некоторые представители сообщества, шутя, высказали претензию, что мы упомянули про аварию GitLab, но в итоге так и не провели подробный разбор полетов. Мы решили исправиться и попросили Алексея написать небольшой «разбор полетов». Основной целью этой публикации является детальный анализ некролога, выделение ключевых моментов, попытка проанализировать их и предложить рекомендации, как следовало бы действовать в подобной ситуации. И, конечно же рассмотрим меры, которые команда GitLab планирует предпринять для предотвращения таких инцидентов в будущем.
Читать полностью »