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

olegbunin вчера в 10:44

БД в облаках: кому и зачем — мнение специалистов Data Egret

• Блог компании Конференции Олега Бунина (Онтико),
• PostgreSQL,
• Администрирование баз данных,
• Облачные вычисления,
• Облачные сервисы

Есть мнение, что будущее за DB as Service. Стоит ли всем подряд увольнять DBA и переходить в публичное облако или стремиться создать приватное облако на Docker с Kubernetes? Трое экспертов из Data Egret — Алексей Лесовский, Виктор Егоров и Андрей Сальников — на канале #RuPostgres в прямом эфире поделились мнением, для каких именно проектов подойдут облачные модели.

Модератором и ведущим беседы выступил Николай Самохвалов, основатель Postgres.ai и сооснователь сообщества RuPostgres.org.



Под катом — расшифровка беседы.

Читать дальше →

Как мы побороли несовместимость при миграции данных с Greenplum 4 на Greenplum 5

• Блог компании Ростелеком,
• Big Data,
• Open source,
• PostgreSQL,
• Администрирование баз данных

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



Дело в том, что файлы баз данных Greenplum версий 4 и 5 не совместимы между собой, и поэтому простой апгрейд от одной версии к другой невозможен. Миграцию данных можно провести только через выгрузку и загрузку данных. В этом посте я расскажу о возможных вариантах этой миграции.

Читать дальше →

Репликация в Tarantool: конфигурирование и использование

• Блог компании Mail.ru Group,
• NoSQL,
• Администрирование баз данных

Я вхожу в Tarantool Core Team и участвую в разработке движка базы данных, внутренних коммуникаций компонентов сервера и репликации. И сегодня расскажу, как устроена репликация.

Читать дальше →

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

• CRM-системы,
• Администрирование баз данных,
• Биллинговые системы,
• Хранение данных

Как мы мигрировали базу данных из Redis и Riak KV в PostgreSQL. Часть 1: процесс

• Блог компании RealtimeBoard,
• PostgreSQL,
• Администрирование баз данных

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



Долгое время основной базой данных в RealtimeBoard был Redis. Мы хранили в нём всю основную информацию: данные о пользователях, аккаунтах, досках и т.д. Всё работало быстро, но мы столкнулись с рядом проблем.

Проблемы с Redis

1. Зависимость от сетевой задержки. Сейчас в нашем облаке она составляет порядка 20 мск, но при её увеличении приложение начнёт работать очень медленно.
2. Отсутствие индексов, которые нужны нам на уровне бизнес-логики. Их самостоятельная реализация может усложнить бизнес-логику и привести к неконсистентности данных.
3. Сложность кода также усложняет обеспечение консистентности данных.
4. Ресурсоёмкость запросов с выборками.

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

Читать дальше →

maxout 24 января 2019 в 09:43

Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации

• Блог компании True Engineering,
• DevOps,
• PostgreSQL,
• Администрирование баз данных,
• Высокая производительность

• Tutorial

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

Читать дальше →

KristinaMyLife 18 января 2019 в 18:24

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

• Блог компании Отус,
• Microsoft SQL Server,
• Администрирование баз данных

Друзья, в конце января у нас стартует новый курс под названием «MS SQL Server разработчик». В преддверии его запуска мы попросили преподавателя курса, Кристину Кучерову, подготовить авторскую статью. Эта статья будет вам полезна, если у вас есть очень популярная таблица на проде с доступом 24/7 и вдруг неожиданно вы поняли, что срочно нужно добавить индекс и ничего не сломать в процессе.

Итак, что же делать? Традиционный способ CREATE INDEX WITH (ONLINE = ON) вам не подходит, потому что, например, вызывает падение системы и сердечный приступ вашего ДБА, все топы пристально следят за response time вашей системы и в случае увеличения оного приходят к вам и вашему ДБА на разговор по поводу завышенных цифр вашей компенсации за труд.

Скрипты и описанные приёмы были использованы на системе с нагрузкой 400К requests per minute, версии SQL Server 2012 и 2016 (Enterprise).

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

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

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

При ошибке приложение сделает повторную попытку обратится к таблице.

Читать дальше →

eapotapov 17 января 2019 в 09:33

Миграция с Mongo на Postgres: опыт газеты The Guardian

• Блог компании ITSumma,
• MongoDB,
• PostgreSQL,
• Администрирование баз данных,
• Системное администрирование

• Перевод

The Guardian — одна из крупнейших британских газет, она основана в 1821 году. За без малого 200 лет существования архив накопился изрядный. По счастью, далеко не весь он хранится на сайте — всего за какие-то последние пару десятков лет. В базе данных, которую сами англичане назвали «источником истины» для всего онлайн-контента, около 2,3 млн элементов. И в один прекрасный момент они осознали необходимость миграции с Mongo на Postgres SQL — после того, как одним жарким июльским днём в 2015 году процедуры аварийного переключения были подвергнуты суровому испытанию. Миграция заняла без малого 3 года!..

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

Читать дальше →

Leono 13 января 2019 в 11:00

Изменение схемы таблиц PostgreSQL без долгих блокировок. Лекция Яндекса

• Блог компании Яндекс,
• PostgreSQL,
• Администрирование баз данных

In-memory базы данных: применение, масштабирование и важные дополнения

• Блог компании Промсвязьбанк,
• IT-инфраструктура,
• Администрирование баз данных,
• Хранение данных

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



В каких случаях стоит переходить на in-memory? Как и зачем масштабировать? И на что стоит обратить внимание? Ответы в выступлениях спикеров, которые мы осветим в этом посте.

Читать дальше →