Администрирование баз данных

Мониторинг Tarantool: логи, метрики и их обработка

Tutorial

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

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

Основы правил проектирования базы данных

• Технотекст 2020
• Tutorial

Введение

Как это часто бывает, архитектору БД нужно разработать базу данных под конкретное решение.
Однажды в пятницу вечером, возвращаясь на электричке домой с работы, я подумал о том, как бы я создал сервис по найму сотрудников в разные компании. Ведь ни один из существующих сервисов не позволяет быстро понять насколько подходит тебе кандидат. Нет возможности создать сложные фильтры, включающие или исключающие совокупность определенных навыков, проектов или позиций. Максимум, что обычно предлагают сервисы — фильтры по компаниям и частично по навыкам.
В данной статье я позволю себе немного разбавить строгое изложение материала, смешав техническую информацию с не техническими примерами из жизни.
Для начала, разберем создание базы данных в MS SQL Server для сервиса поиска соискателей на работу.
Этот материал можно перенести и на другую СУБД такую как MySQL или PostgreSQL.

Зарплата администратор БД

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

Федеральной Службой Государственной Статистики была выявлена средняя зарплата специалиста в сфере администрирования БД. По итогам 2021 г. установлено:

• Москва и московская область — от 79 000 до 100 000 рублей;
• СПб и ленинградская область — от 61 000 до 80 000 рублей;
• Новосибирск — от 52 000 до 70 000 рублей;
• Томск — от 27 000 до 50 000 рублей
• Регионы — от 40 000 до 65 000 рублей.

В наименее развитых регионах зарплата админа БД устанавливается ниже столичных показателей. Однако это не распространяется на узко квалифицированных специалистов.

Путеводитель по резервному копированию баз данных

Резервным копированием называется сохранение копии данных где-то вне основного места их хранения.
Главное назначение резервного копирования – восстановление данных после их потери. В связи с этим нередко приходится слышать, что при наличии реплики базы данных с неё всегда можно восстановить данные, и резервное копирование не нужно. На самом деле резервное копирование позволяет решить как минимум три задачи, которые не могут быть решены при помощи реплики, да и реплику без резервной копии не инициализировать.
Во-первых, резервная копия позволяет восстановить данные после логической ошибки. Например, бухгалтер удалил группу проводок или администратор БД уничтожил табличное пространство. Обе операции абсолютно легитимны с точки зрения базы данных, и процесс репликации воспроизведёт их в базе-реплике.
Во-вторых, современные СУБД – весьма надёжные программные комплексы, однако изредка всё же происходит повреждение внутренних структур базы данных, после которого доступ к данным пропадает. Что особенно обидно, такое нарушение происходит обычно при высокой нагрузке или при установке какого-нибудь обновления. Но как высокая нагрузка, так и регулярные обновления говорят о том, что база данных – отнюдь не тестовая, и данные, хранящиеся в ней, ценны.
Наконец, третья задача, решение которой требует наличия резервной копии, – это клонирование базы, например, для целей тестирования.
Резервное копирование баз данных так или иначе базируется на одном из двух принципов:

• Выборка данных с последующим сохранением в произвольном формате;
• Снимок состояния файлов БД и сохранение журналов.

Давайте рассмотрим эти принципы и реализующие их инструменты подробнее.

Этюд — логическая репликация для копирования баз данных PostgreSQL

Постановка задачи

От бизнеса поступила задача — необходимо регулярно сохранять копии отдельных баз данных, расположенных в разных кластерах PostgreSQL.
Упрощенно говоря — бекапить отдельные базы данных, на случай сверки или потери данных в исходных базах. Первое и самое очевидное решение — pg_dump
Достоинства — простота решения. Штатные методы. Все отработано, документации и материалов великое множество.Но, достоинства есть продолжения недостатков. Во-первых: объемы дампов.Во-вторых: и это самое неприятное, были случаи несовпадения исходной и целевой БД при восстановлении из дампа.В-третьих: время, сначала на создание дампа, потом на восстановление БД из дампа.
В итоге — нужно искать другой путь копирования БД между серверами. Бизнес требовал, задача интересная.

Подходы к обеспечению безопасности БД

Существует два подхода к управлению защитой данных: избирательный и обязательный.

Защищаемым объектом в обоих случаях может быть как полная база данных, так и любая ее часть.

При избирательном подходе к защите данных:

• пользователь, работающий с различными объектами базы данных, имеет на каждый из них неравные права (привилегии);
• несколько пользователей имеют разную степень доступа к одним и тем же данным. 

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

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

Для обеспечения безопасности данных производится:

• проверка полномочий пользователя;
• аутентификация его личности.

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

Привилегии остальных пользователей устанавливаются в зависимости от рода их деятельности и уровня ответственности.

Например:  В процессе работы персонала используется определенная таблица с данными. Доступ к ней имеют три пользователя: U1, U2 и U3:

1. U1 – создатель таблицы. Он имеет право передавать ее U2 и U3, но не уполномочен вносить что-либо от себя;2. U2 – оператор, который вносит изменения в таблицу данных. Ему дается право на исправление показателей в отдельном столбце (например, цен на товары);3. U3 – начальник, который должен ежедневно следить за динамикой изменения данных. Он имеет право только на просмотр всех строк.

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

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

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

Поиск данных и объектов в базе данных MS SQL Server с помощью бесплатной утилиты dbForge Search

Tutorial

Описание общей потребности в поиске данных и объектов в базе данных

Поиск данных, а также хранимых процедур, таблиц и других объектов в базе данных является достаточно актуальным вопросом в том числе и для C#-разработчиков, а также и для .NET-разработки в целом.
Достаточно часто может возникнуть ситуация, при которой нужно найти:

1. объект базы данных (таблицу, представление, хранимую процедуру, функцию и т д)
2. данные (значение и в какой таблице располагается)
3. фрагмент кода в определениях объектов базы данных

Существует множество готовых решений как платных, так и бесплатных.
Сначала рассмотрим как можно осуществлять поиск данных и объектов в базе данных с помощью встроенных средств самой СУБД, а затем рассмотрим как это сделать с помощью бесплатной утилиты dbForge Search.

Рабочая ОС системного администратора

Начнем с операционной системы системного администратора. Лично я работал и работаю только на ОС Windows. Раньше это была Windows 7, сейчас Windows 10. Ниже напишу свое мнение на счет этих ОС. А пока просто объясню, почему именно Windows.

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

1. Лучшая поддержка ПО и драйверов. У вас почти никогда не будет проблем с тем, что какого-то драйвера или программы нет под вашу систему.
2. Стабильная и надежная работа. В основном этот плюс относится к Windows 7, про десятку такого не скажу. А вот семерка у меня без проблем работала и работает месяцами без перезагрузки.
3. Простая интеграция в другие информационные системы. Легко подключить сетевую папку, принтер в новом офисе, подключиться к vpn. Я часто перемещаюсь между офисами, для меня это актуально.

Windows — операционная система для тех, кто просто хочет сесть и начать работать, а не настраивать систему, искать драйвера для тачпада, видеокарты корректной работы hibernation и т.д.

Больше ничего в голову не пришло 🙂 Конечно, решающее значение имеет именно первый пункт. Например, для управления XenServer существует приложение Citrix XenCenter только под Windows. Конечно, при наличии виртуальных машин этот вопрос немного сглаживается, но тем не менее, я предпочитаю, когда все рабочие инструменты на одной системе. Под Windows существует огромное количество ПО на любой вкус. Ниже я как раз и расскажу, какие программы под windows я использую для системного администрирования.

Пару лет назад я перешел с Windows 7 на Windows 10. Мотивов для этого перехода было совсем немного:

1. Мне нравился новый диспетчер задач.
2. Мне хотелось в cmd пользоваться ctrl+c и ctrl+v.
3. Просто любопытно было посмотреть на новую систему.

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

1. Назойливая система обновлений. Сколько я с ней промучался, но так ее и не победил. Смирился и регулярно обновляюсь. Хорошо, хоть ошибок пока нет.
2. Перепутаны все настройки. Часть в Панели управления осталась, часть переехала в Настройки. Мало того, что так неудобно, так в самих Настройках от обновления к обновлению меняется расположение настроек. Подключиться к VPN, посмотреть статус сетевого подключения, разрешить отображение значков в трее стало очень неудобно. Хорошо, что еще осталась панель управления старая. Что будет, если ее уберут — не знаю.
3. Система периодически что-то делает в фоне, нагружает процессор и сжирает ресурс батареи на ноутбуке. Для меня это очень актуально, так как имею Thinkpad x220 с очень емкой батареей. Могу работать от нее несколько часов, но не тогда, когда windows 10 решает что-то посчитать в фоне. Причем работает системный процесс и ты не можешь понять, что конкретно делает система. Я и так и сяк подходил к этой проблеме, но так и не понял, что конкретно надо сделать, чтобы система перестала вести непонятную деятельность. Даже полное отключение обновление не помогало. Иногда система все равно что-то делала. Я сразу замечал это, так как вентиляторы на ноуте начинают громче гудеть. Иногда помогала перезагрузка компьютера, иногда нет.
4. Глючит буфер обмена. Иногда он тормозит. Иногда из него выходят знаки вопросов. Иногда он добавляет очень много пробелов между строк. Это настоящее бедствие, так как очень мешает работе. Помогает перезагрузка, но в середине рабочего дня, во время активной работы перезагружаться не вариант.

Минусов гораздо больше, не хочу сейчас на этом делать акцент, так как статья о другом. Но конкретно эти вещи меня очень напрягают и в целом мне не нравится эта система. Она не удобна для работы. Не перехожу обратно на Windows 7, так как ее меньше чем через 2 года снимут поддержки, а я не люблю переустанавливать системы. Очень много времени на это тратится. Вот и приходится терпеть недостатки. Возможно, переустановка системы на LTSB версию решит проблемы, но пока никак не соберусь на перестановку.

Насчет операционной системы все. Вот пример рабочего стола системного администратора, то есть меня 🙂

Valentina Studio — бесплатная программа для работы с СУБД

Очень многие разработчики считают что лучший интерфейс для работы с базами данных — текстовый интерфейс консольного. Я лично еще не достиг подобного просветления, поэтому больше доверяю GUI-инструментам. Хорошо, если у СУБД как у Postgres есть своя, утилита для работы с БД, а что делать если нет? Или если надо работать с различными базами данных одновременно? Под Windows альтернативных клиентов к различным СУБД — море разливанное. С другими ОС (я в данный момент работаю в OS X) все не так радужно, хотя есть программы разной степени пригодности и удобства. Раньше я использовал Navicat, но недавно нашел еще одно интересное решение, о котором и хочу рассказать: Valentina Studio.
Сразу скажу — я общался с разработчиками, и мне очень импонирует их концепция, то что они делают и как, поэтому я решил просто написать обзор о хорошем инструменте, о котором мало кто знает, поскольку публичный релиз программы состоялся очень недавно. До этого она долгое время разрабатывалась для Valentina DB и только в феврале вышла версия с поддержкой известных популярных баз данных. При этом разработчики приняли достаточно разумное решение — базовая версия совершенно бесплатна, а деньги берут только за несколько мощных «особо профессиональных» функций без которых чаще всего можно обойтись.

Чем занимается администратор баз данных

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

Профессия классифицируется на подструктуры. Администратор БД может работать на аналитическом направлении, заниматься созданиями и исследованиями систем, сформированных под определенные требования. Есть категория сотрудников, которые работают над оптимизацией процессов, обеспечением целостности и неприкосновенности хранилищ данных. В штате компании нужен человек, способный решать проблемные ситуации, ликвидировать последствия сбоев.

Что входит в основные задачи

Если объединить приоритетные задачи, которые должен решать администратор БД, без уточнения отраслевой специфики компании, то выделяются следующие:

1. Оптимизация производительности. Система должна не только просто функционировать, а делать это по рациональной и максимально выгодной схеме.
2. Проектирование базы данных. Потребности компании могут меняться, что ведет к появлению необходимости совершенствовать системы, внедрять дополнительные разработки.
3. Обеспечение безопасности. Для каждой базы требования к защите имеет определенный уровень, что обязательно должно быть учтено администратором.
4. Резервирование, копирование и при необходимости восстановление баз данных.
5. Организация процесса по обеспечению целостности информации.

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

Данные актуальны на Май 2021 и взяты из сервиса «Яндекс Работа»

Обязанности

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

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

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

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

1С и Яндекс.Облако Compute Cloud. Вдоль и поперек

Бороться и искать. Найти и перепрятать
Достаточно популярная поговорка во времена Союза.
Вот и сейчас, те у кого сервер 1С в локальной сети мечтают вынести его в облако, а те у кого в облаке прикупить свой в локальную сеть.
7 декабря 2018 г. AlexandrSurkov пригласил желающих: Яндекс открывает Облако. Архитектура новой платформы
Как у обычного пользователя у меня не нашлось чем занять этот ресурс, но как 1С-ник я подумал: А пуркуа бы и не па ? И попробовал положить в облако от Яндекса 1С Предприятие.
Тестирование Яндекс.Облако Compute Cloud для 1С Предприятие оставило у меня приятное впечатление.
Возможно кто-то повторит его и внесет больше ясности в настройки виртуальных серверов, использованию API и так далее. Интересующихся прошу продолжить чтение…

Способы диагностики PostgreSQL — Владимир Бородин и Ильдус Курбангалиев

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

РИТ++ 2020: консультации с инженерами Авито в Зуме

Привет, Хабр! 25 и 26 мая будет РИТ++. Это большая онлайн-конференция для всех, кто делает интернет. В обычных условиях мы бы встретились на стенде Авито в зале мероприятия, но 2020 перевернул всё с ног на голову. Так что общение переносится в Зум, где 11 наших инженеров из разных команд ответят на вопросы про базы данных, перформанс, мониторинг, микросервисную архитектуру и многое другое.

Участвовать в консультации можно независимо от того, есть у вас билет на конференцию или нет. Все встречи доступны любому желающему. Расписание, экспертные области участников и нужные ссылки — под катом. Кроме консультаций мы подготовили пару развлечений, о них в конце анонса.

Как мы тестировали несколько баз данных временных рядов

За последние несколько лет базы данных временных рядов (Time-series databases) превратились из диковинной штуки (узкоспециализированно применяющейся либо в открытых системах мониторинга (и привязанной к конкретным решениям), либо в Big Data проектах) в «товар народного потребления». На территории РФ отдельное спасибо за это надо сказать Яндексу и ClickHouse’у. До этого момента, если вам было необходимо сохранить большое количество time-series данных, приходилось либо смириться с необходимостью поднять монструозный Hadoop-стэк и сопровождать его, либо общаться с протоколами, индивидуальными для каждый системы.
Может показаться, что в 2019-м году статья про то, какую TSDB стоит использовать, будет состоять лишь из одного предложения: «просто используйте ClickHouse». Но… есть нюансы.
Действительно, ClickHouse активно развивается, пользовательская база растет, а поддержка ведется очень активно, но не стали ли мы заложниками публичной успешности ClickHouse’а, которая затмила другие, возможно, более эффективные/надежные решения?
В начале прошлого года мы занялись переработкой нашей собственной системы мониторинга, в процессе которой встал вопрос о выборе подходящей базы для хранения данных. Об истории этого выбора я и хочу здесь рассказать.

Образование

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

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

Набирают популярность и специальные курсы, дистанционное образование. Эти методы обучения используются в качестве дополнительной квалификации или ее повышения. В любом случае необходима основная профессиональная специализация, полученная в ВУЗе.

Защита от сбоев.

База данных 1С зачастую является основным местом хранения фактов хозяйственной деятельности предприятия. Так база данных программы 1С WMS Управление складом содержит информацию об управлении и функционировании всего складского комплекса предприятия. В случае потери или недоступности базы данных, восстановление утерянной информации может быть весьма трудоемким и длительным процессом.

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

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

Первичной задачей администратора БД в области защиты от сбоев является определение приемлемых для бизнеса границ потери информации и допустимых временных рамках простоев с учетом располагаемых и доступных ресурсов.

Основной же задачей администратора является разработка, внедрение и поддержка плана по обеспечению требований бизнеса.

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

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

Знакомство с pg_probackup. Первая часть

• Технотекст 2020
• Tutorial

Привет, я Александр Никитин, главный системный администратор компании «БАРС Груп». В этой статье я хочу познакомить вас с инструментом pg_probackup.Pg_probackup — разработка компании Postgres Professional, которая помогает делать резервные копии СУБД PostgreSQL. В отличие от стандартной утилиты pg_basebackup этот инструмент позволяет создавать инкрементные резервные копии на уровне блоков данных (по умолчанию 8Kb), производить валидацию резервных копий и СУБД, задавать политики хранения и многое другое.
В этой статье я не ставлю перед собой цели описать все возможные аспекты работы с pg_probackup, я лишь хочу дать понимание того, как вы можете использовать этот инструмент в своей работе.
Будут рассмотрены следующие варианты использования:

• создание автономных бэкапов на отдельном сервере
• создание архива wal-файлов и создание бэкапов в этом режиме
• развёртывание реплики из бэкапа и настройка создания бэкапов с реплики
• различные варианты восстановления

Моделирование отказоустойчивых кластеров на базе PostgreSQL и Pacemaker

Введение

К этому решению возник резонный вопрос: насколько отказоустойчивым будет отказоустойчивый кластер? Чтобы это исследовать, я разработал тестовый стенд, который имитирует различные отказы на узлах кластера, ожидает восстановления работоспособности, восстанавливает отказавший узел и продолжает тестирование в цикле. Изначально этот проект назывался hapgsql, но со временем мне наскучило название, в котором только одна гласная. Поэтому отказоустойчивые базы данных (и float IP, на них указывающие) я стал именовать krogan (персонаж из компьютерной игры, у которого все важные органы дублированы), а узлы, кластеры и сам проект — tuchanka (планета, где живут кроганы).

Как быстро удалить множество строк из большой базы в MySQL

Tutorial

Как известно, все системные администраторы делятся на две категории. Те, кто уже делают бэкапы и те, кто ещё нет.
Подобно им, администраторы БД также делятся на две категории, те, кто уже запускал процедуру удаления на большой БД с типом таблиц InnoDB, и те, кому это ещё предстоит.
Разумеется, в теории все знают, что из-за особенностей InnoDB, удаление может быть долгим, но это знание сродни тому, что «надо делать бэкапы». Многие осознают эти нехитрые истины, только наступив на грабли.
Для понимания, удаление 350М записей в таблице на 500М записей может занять более двух суток. Вторые грабли, на которые многие наступают, это попытка прибить запрос. Как мы все помним, InnoDB движок транзакционный, поэтому если вы попытаетесь прибить запрос, он попытается откатить изменения, а это может занять больше времени, чем выполнялся запрос.
Как сделать так, чтобы не было мучительно больно? Добро пожаловать под кат!

Знакомство с СУБД CockroachDB и создание отказоустойчивого кластера с ней на Ubuntu 16.04

• Перевод
• Tutorial

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

Введение

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

InnoDB cluster — оно работает, и вроде бы именно так, как обещали

Tutorial

Я занимаюсь АТСками. И как-то так сложилась, что с самого первого заказа от меня хотели отказоустойчивости. Одним из ключевых компонентов современной АТС (как и любой информационной системы, наверное) является БД, где хранятся как данные о текущем состоянии системы, так и всякие конфигурационные параметры. Естественно, падение БД приводит к поломке всей системы. Начиналось все с MASTER-MASTER репликации в MySQL (исключительно для оперативности переключения), потом были эксперименты с MySQL over DRBD. Все это жило в pacemaker/corosync инфраструктуре. Там ездили IP-адреса, шлюзы и прочая лабудень. Со временем оно даже стало работать как-то более-менее устойчиво. Но тут мне попалась пара серверов, на которых DRBD сделать было нельзя, в MASTER-MASTER я разочаровался довольно давно (постоянно она у меня ломается, такая репликация), а без отказоустойчивой БД терялся весь смысл решения. На глаза мне попалось название InnoDB cluster и я решил: «была-не-была». Что из этого получилось — смотрите под катом.

Типы

Есть три типа администраторов баз данных:

1. Системные администраторы баз данных (также называемые физическими администраторами баз данных, операционными администраторами баз данных или производственными администраторами баз данных): сосредоточьтесь на физических аспектах администрирования базы данных, таких как установка СУБД, настройка, исправление, обновления, резервное копирование, восстановление, обновление, оптимизация производительности, обслуживание и аварийное восстановление .
2. Администраторы баз данных-разработчиков: сосредоточьтесь на логических аспектах и ​​аспектах разработки администрирования баз данных, таких как проектирование и обслуживание модели данных, создание DDL ( языка определения данных ), написание и настройка SQL, кодирование хранимых процедур , сотрудничество с разработчиками, чтобы помочь выбрать наиболее подходящую функцию СУБД / функциональность и другие предпроизводственные мероприятия.
3. Администраторы баз данных приложений: обычно встречаются в организациях, которые приобрели стороннее прикладное программное обеспечение, такое как системы ERP ( планирование ресурсов предприятия ) и CRM ( управление взаимоотношениями с клиентами ). Примеры такого прикладного программного обеспечения включают Oracle Applications , Siebel и PeopleSoft (оба теперь являются частью Oracle Corp.) и SAP. Администраторы баз данных приложений балансируют между СУБД и прикладным программным обеспечением и несут ответственность за обеспечение полной оптимизации приложения для базы данных и наоборот. Обычно они управляют всеми компонентами приложения, которые взаимодействуют с базой данных и выполняют такие действия, как установка и исправление приложений, обновление приложений, клонирование базы данных, создание и выполнение процедур очистки данных, управление процессом загрузки данных и т. Д.

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

Как добавить индекс на нагруженной системе 24/7 без простоя?

Друзья, в конце января у нас стартует новый курс под названием «MS SQL Server разработчик». В преддверии его запуска мы попросили преподавателя курса, Кристину Кучерову, подготовить авторскую статью. Эта статья будет вам полезна, если у вас есть очень популярная таблица на проде с доступом 24/7 и вдруг неожиданно вы поняли, что срочно нужно добавить индекс и ничего не сломать в процессе.
Итак, что же делать? Традиционный способ CREATE INDEX WITH (ONLINE = ON) вам не подходит, потому что, например, вызывает падение системы и сердечный приступ вашего ДБА, все топы пристально следят за response time вашей системы и в случае увеличения оного приходят к вам и вашему ДБА на разговор по поводу завышенных цифр вашей компенсации за труд.
Скрипты и описанные приёмы были использованы на системе с нагрузкой 400К requests per minute, версии SQL Server 2012 и 2016 (Enterprise).
Есть два очень разных подхода создания индекса, которые используются в зависимости от размера таблицы.

Кейс № 1. Маленькая, но очень популярная таблица

Таблица 50 тыс. записей (небольшая), но очень популярная (несколько тысяч обращений в минуту). Вам нужен новый индекс и минимальное время простоя и блокировок на таблице.
В приложении весь доступ к БД только через процедуры.
При ошибке приложение сделает повторную попытку обратится к таблице.

Кластер высокой доступности на postgresql 9.6 + repmgr + pgbouncer + haproxy + keepalived + контроль через telegram

• Tutorial

На сегодняшний день процедура реализации «failover» в Postgresql является одной из самых простых и интуитивно понятных. Для ее реализации необходимо определиться со сценариями файловера — это залог успешной работы кластера, протестировать его работу

В двух словах — настраивается репликация, чаще всего асинхронная, и в случае отказа текущего мастера, другая нода(standby) становится текущем «мастером», другие ноды standby начинают следовать за новым мастером.
На сегодняшний день repmgr поддерживает сценарий автоматического Failover — autofailover, что позволяет поддерживать кластер в рабочем состоянии после выхода из строя ноды-мастера без мгновенного вмешательства сотрудника, что немаловажно, так как не происходит большого падения UPTIME. Для уведомлений используем telegram.
Появилась необходимость в связи с развитием внутренних сервисов реализовать систему хранения БД на Postgresql + репликация + балансировка + failover(отказоустойчивость)

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