Рубрика «Администрирование баз данных» - 24

в 6:38, , рубрики: 1С, 1С-Битрикс, Администрирование баз данных, Облачные вычисления, облачные сервисы, яндекс, яндекс.облако

Бороться и искать. Найти и перепрятать

Достаточно популярная поговорка во времена Союза.

Вот и сейчас, те у кого сервер 1С в локальной сети мечтают вынести его в облако, а те у кого в облаке прикупить свой в локальную сеть.

7 декабря 2018 г. AlexandrSurkov пригласил желающих: Яндекс открывает Облако. Архитектура новой платформы

Как у обычного пользователя у меня не нашлось чем занять этот ресурс, но как 1С-ник я подумал: А пуркуа бы и не па ? И попробовал положить в облако от Яндекса 1С Предприятие.

Тестирование Яндекс.Облако Compute Cloud для 1С Предприятие оставило у меня приятное впечатление.

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

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

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

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

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

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

Под катом — расшифровка беседы.
Читать полностью »

в 7:07, , рубрики: nosql, tarantool, Администрирование баз данных, Блог компании Mail.Ru Group, репликация

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

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

в 12:05, , рубрики: database migrations, postgres, postgresql, realtimeboard, redis, riak, Администрирование баз данных, Блог компании RealtimeBoard, миграция базы данных

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

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

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

Проблемы с Redis

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

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

в 6:43, , рубрики: devops, high availability, linux, postgresql, replication, Администрирование баз данных, Блог компании True Engineering, высокая производительность, отказоустойчивость

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

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

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

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

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

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

TL;DR

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

Читать полностью »

в 15:24, , рубрики: 24/7, highload, Microsoft SQL Server, sqlserver, Администрирование баз данных, Блог компании Отус, высокая доступность, индексы, миграция данных

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

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

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

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

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

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

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

Как добавить индекс на нагруженной системе 24-7 без простоя? - 1
Читать полностью »

в 6:33, , рубрики: mongodb, postgresql, Администрирование баз данных, базы данных, Блог компании ITSumma, миграция, перевод, системное администрирование

image

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

Читать полностью »

в 8:00, , рубрики: concurrency, constraints, django, postgresql, Администрирование баз данных, Блог компании Яндекс, блокировки SQL, даунтайм, таблицы данных

Если одновременно выполняется много операций по изменению схемы БД, сервис не может корректно работать на запись. Разработчик Владимир Колясинский объяснил, какие операции в PostgreSQL требуют длительных блокировок и как команда Яндекс.Коннекта обеспечивает почти стопроцентную доступность сервиса на запись во время выполнения подобных операций. Кроме того, вы узнаете о библиотеке для Django, которая призвана автоматизировать часть описанных процессов.

У нас большие нагрузки, тысячи RPS, и простой в несколько минут, не говоря о большем времени, недопустим. Нужно, чтобы миграции происходили незаметно для пользователя. А с такими нагрузками уже не получится встать в четыре часа ночи, что-то накатить, когда нет нагрузки, и снова лечь спать — потому что нагрузка идет круглые сутки.

Читать полностью »

в 14:27, , рубрики: in-memory, Администрирование баз данных, базы данных, Блог компании Промсвязьбанк, Промсвязьбанк, хранение данных

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

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

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

в 9:33, , рубрики: administration, Microsoft SQL Server, mssql, powershell, storage, VMware, Администрирование баз данных, виртуализация, Серверное администрирование

Каждый день мне приходится добавлять место на одном, двух, трех, пяти, а бывает – и десяти database серверах. Почему? Потому что для них характерен естественный рост баз. Серверов сотни, все они виртуалки с дисками на thin provisioning. Если им заранее выдать много места, то будет обязательно какой нибудь “runaway”, типа апгрейда с переливом таблиц, который пожрет все это место, а если не пожрет, то поднадкусает. Как вы знаете, thin provisioning – это путь в одну сторону, если место сожрано, но то его назад не вернуть.

В итоге большинство серверов болтаются где то у границы 90% space used – именно потому, что на границе 90% срабатывает алерт. Как только я даю немного, именно немного места – сервер отправляется в район 80%-85% used, и через месяц другой место надо добавлять снова. И, тем не менее, много сразу давать не буду – слишком много прецедентов с runaways.

Я так часто делал механическую работу по расширению места на дисках, что мне это надоело и я решил это автоматизировать с помощью Jenkins:

Утро админа: добавляем место на десятках серверов за кофе - 1
Читать полностью »

1...1020...232425...3040...64
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js