Базы данных *

Разработанная инженерами Uber система хранения данных Schemaless используется в нескольких самых важных и крупных сервисах нашей компании (например, Mezzanine). Schemaless — это масштабируемое и отказоустойчивое хранилище данных, работающее поверх кластеров MySQL¹. Когда этих кластеров было 16, управление ими было несложным делом. Но в настоящий момент у нас их более 1 000, и в них развернуто не менее 4 000 серверов баз данных. Управление такой системой требует инструментов совсем другого класса.

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

Данная статья может быть интересна тем, кто уже имеет поверхностное представление о видах и проблематике репликации внутри кластера PostgreSQL, а так же тем, кто решил использовать стриминговую СУБД PipelineDB в качестве реплики в подобном кластере.

PipelineDB — одна из реализаций ныне набирающих популярность стриминговых СУБД. О преимуществах стриминговых СУБД в различных кейсах Вы можете без труда прочитать сегодня на множестве ресурсов. Очень просто принцип их работы визуализирован на сайте www.pipelinedb.com в разделе “How It Works”.

Конкретно PipelineDB это форк PostgreSQL с дополнительной функциональностью, позволяющей хранить только агрегированные данные, рассчитывая дельту из поступающего стрима (отсюда и название этого типа СУБД) на лету. Эти данные хранятся в специальных объектах PipelineDB, называемых continuous views. Сам же стрим в простейшем случае формируется из обычных таблиц, хранимых в этой же БД. Использование данного инструмента позволяет нам избавиться от необходимости создания и поддержки ETL-слоя при подготовке данных для систем отчетности, и может сэкономить Вам кучу времени и нервов. Но я полагаю, что раз Вы это читаете, то Вы уже что-то знаете об этом в объеме достаточном для появления интереса к описываемым здесь событиям.

Мы рассмотрим кейс, в котором на продуктовой среде у нас уже работает СУБД PostgreSQL версии 9.4+, а нам нужно получить ее риалтайм (ну или практически риалтайм) реплику для того, чтобы разгрузить основную базу от множественных и тяжелых SELECT-запросов, получаемых от, например, систем отчетности, DWH или наших витрин данных. И после изучения вопроса Вы можете решить, что именно стриминговая СУБД очень хорошо подходит для такой задачи.

Предисловие

В данной статье будут разобраны основные регламентные работы с базой данных информационной системы 24x7 (т е у которой нет простоя) и подходы к их выполнению в MS SQL Server. Также прошу заметить, что эта статья будет кратким обзором, т е не все работы будут достаточно детализированы. Однако, данной информации достаточно, чтобы при необходимости изучить более детально ту или иную регламентную работу.

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

Привет, Хабр! Встала передо мной недавно задача: настроить максимально надежный кластер серверов PostgreSQL версии 9.6.

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

Планируя кластер я проштудировал много статей, как из основной документации к PostgreSQL, так и различных howto, в том числе с Хабра, и пробовал настроить стандартный кластер с RepMgr, эксперементировал с pgpool.

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

В итоге где-то (уже не вспомню точно где) нашел ссылку на прекрасный проект Zalando Patroni, и все заверте…

Вкратце напомню: BRMS, или Business Rule Management System, — это «тяжёлые» системы для крупных и очень крупных компаний, которые содержат все те вещи, которые часто меняются в ИТ. Например, в банке в BRMS лежат чаще всего правила оценки по кредиту и параметры вкладов, в сотовом операторе — тарифы и нюансы вычисления всех списаний, в страховой компании — коэффициенты страхования, поправочные коэффициенты, параметры новых продуктов.

Разница между «вобьём руками» и «вобьём через BRMS» примерно такая: парни из одной страховой компании, где мы внедряли BRMS, оказались одними из немногих по итогам прошлого года, кто показал возможность работать очень гибко и быстро. Обычно внедрение коэффициента со всеми проверками занимает в среднем 2 недели. Здесь же это делается максимум за 2 дня, минимум — за считанные часы. У них есть данные статистики, на которые крайне быстро можно реагировать и перепроверять разные показатели сотни и тысячи раз. В страховании это означает возможность очень детально подстраиваться под текущую ситуацию (регион, банки) и получать куда больше прибыли.

Мы используем BRMS для оценки стоимости ИТ-проекта — она рассчитывается на основе правил вроде «работают сетевики либо программисты» и десятков переменных вроде стоимости часа специалиста.

Была поставлена задача: реализовать мониторинг БД Oracle средствами Zabbix, а именно — отслеживать параметры табличных пространств на определенном инстансе. Раз задача поставлена, значит делаем. Как известно, Zabbix предоставляет возможность через предопределенный тип данных осуществлять запросы к базам данным и получать результат запроса. На официальном сайте разработчиков Zabbix есть очень хорошая документация по настройке ODBC-мониторинга.

У нас сервер Zabbix 3.0.4 под управлением Centos 7. Ранее ODBC мониторинг не был настроен, а следовательно, нужно открывать инструкции и начинать установку и настройку.

Google открыла для всех бета-версию сервиса Cloud Spanner, глобально распределённой высокомасштабируемой мультиверсионной NewSQL БД с поддержкой распределённых транзакций.

Несколько лет Google использовала этот сервис исключительно для внутренних нужд. На нём работают ключевые системы Google, в том числе AdWords и Google Play. Spanner — эволюционное развитие NoSQL-предшественника Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений, то есть оно сочетает в себе преимущества реляционных и нереляционных СУБД. Это ACID-транзакции и SQL-синтаксис традиционных СУБД без ущерба для горизонтального масштабирования и высокой доступности, присущих NoSQL.

Исходя из опыта работы системы внутри компании, Google предлагает клиентам аптайм 99,9999% (шесть девяток, то есть максимум 31,5 секунды простоя в год), клиентские библиотеки с поддержкой Java, Go, Python, Node.js и др.

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

Аркадий и Борис Стругацкие

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных и сам сервис ушел в офлайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими. Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы. It, как говорится, happens. Но надо отдать должное команде проекта: они нашли в себе силы отнестись ко всему с юмором, не потеряли голову и проявили удивительную открытость, написав обо всем в твиттере и выложив в общий доступ, по сути, внутренний документ, в котором команда в реальном времени вела описание разворачивающихся событий.

Во время его чтения буквально ощущаешь себя на месте бедного YP, который в 11 часов вечера после тяжелого трудового дня и безрезультатной борьбы с Постгресом, устало щурясь, вбивает в консоль боевого сервера роковое sudo rm -rf и жмет Enter. Через секунду он понимает, что натворил, отменяет удаление, но уже поздно — базы больше нет...

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

Я присоединился к команде Facebook в 2011 году в качестве инженера бизнес-аналитика. К моменту, когда я покинул команду в 2013 году я уже был дата-инженером.

Меня не продвигали или назначали на эту новую позицию. Фактически, Facebook пришла к выводу, что выполняемая нами работа является классической бизнес-аналитикой. Роль, которую в итоге мы для себя создали, была полностью новой дисциплиной, а я и моя команда находились на острие этой трансформации. Мы разрабатывали новые подходы, способы решения задач и инструменты. При этом, чаще всего, мы игнорировали традиционные методы. Мы были пионерами. Мы были дата-инженерами!

Дата-инжиниринг?

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

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

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

Дело было примерно так.

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

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

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

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

Состоявшиеся в уже прошедшем 2016 году выборы в Государственную Думу Федерального Собрания Российской Федерации VII созыва, которые опирались на Государственную автоматизированную систему Российской Федерации «Выборы», предназначенную для автоматизации избирательных действий, напомнили о том как проходила подготовка к аналогичным мероприятиях в 90-ые годы прошлого столетия. С точки зрения IT-индустрии и IT-технологий, это были тяжелейшие годы, компьютеров и принтеров не просто не хватало, во многих местах их просто не было.

Начало приватизационного процесса

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

Prometheus – одна из систем мониторинга, адаптированных под сбор time series данных.
Она достаточно проста в инсталляции и первоначальной настройке. Имеет встроенную графическую подсистему для отображения данных PromDash, однако сами же разработчики рекомендуют использовать бесплатный сторонний продукт Grafana. Prometheus умеет мониторить много чего («железо», контейнеры, различные СУБД), однако в данной статье хотелось бы остановиться на реализации мониторинга инстанса Caché (точнее, инстанс будет Ensemble, но метрики будем брать кашовые). Кому интересно — милости просим под кат.

Развитие мобильного широкополосного доступа выдвигает новые требования к беспроводным сетям. Во-первых, требуется обеспечить стабильное покрытие сетей 3G/4G, особенно в густонаселенных городах с большим трафиком данных, затем – удовлетворить стремительно растущий спрос на интернет-трафик. Однако на пути решения вышеуказанных задач мы сталкиваемся с проблемами, связанными с работой макро базовых станций.

Предлагаю Вашему вниманию реализацию 2FA в Oracle Application Express. В качестве второго фактора будет использовано решение от Google с установленным на телефон приложением Authenticator.

Типовой сценарий работы «just in time» хранилища данных выглядит так: десятки (ETL) сессий почти непрерывно захватывают с источников данные и вставляют их в хранилище. Параллельно множество других (ELT) сессий отслеживают поступление данных, заполняют консолидированный слой и ведут расчет агрегатов и витрин. Одновременно с этим, на поступающих первичных и рассчитанных данных, выполняют запросы пользователи, BI и другие системы. Вся эта каша должна ладно вариться в рамках сервера хранилищ данных, без тормозов и затыков, какими бы не были пиковые нагрузки.

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

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

«Если вы можете кэшировать всё очень эффективным способом, то вы часто можете изменить правила игры»

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

• Метаданные продукта в интернет-магазине
• Метаданные документа в поисковой машине
• Метаданные фильмов и ТВ-шоу

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

• Хранение этих данных в каком-то централизованном хранилище (например, реляционная СУБД, информационный склад NoSQL или кластер memcached) для удалённого доступа пользователей
• Сериализация (например, как json, XML и т.д.) и распространение среди потребителей, которые будут хранить локальную копию

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

При активной разработке ПО нередко нужна тестовая база с актуальными данными из боевой базы. Хорошо, если база маленькая и развернуть копию не долго. Но если в базе десятки гигабайт данных и все нужны для полного тестирования, да ещё и посвежее, то возникают трудности. В этой статье я опишу вариант преодоления подобных неприятностей с помощью snapshot-ов btrfs. А управлять работой получившегося комплекса будет systemd – удобный и функциональный инструмент.

Когда я устроился на новую работу, передо мной была поставлена первая задача — разобраться, почему один из экземпляров SQL очень сильно нагружает диски. И предпринять необходимые действия для устранения этой ужасной проблемы. Я еще не сказал, что дисковый пул был всего один, и что при нагрузке на диски страдали все экземпляры сиквела? Так вот это было так. Что самое главное, как оказалось, мониторинг в лице Zabbix не собирал необходимые метрики, а на добавление оных нужно было заводить заявку и ждать. Ждать и смотреть, как «горит» дисковый массив. Или…

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

Для начала создадим БД и объекты, необходимые для сбора метрик производительности SQL-сервера.