#репликация — Public Fediverse posts

Как мы разворачиваем ClickHouse-кластер через Arenadata: практический гайд для DevOps

Привет, Хабр! Меня зовут Никита Ивкин, я — ведущий DevOps-инженер РТЛабс, работаю с инфраструктурой Госуслуг. Сегодня я покажу один из наших реальных сценариев: как мы разворачиваем ClickHouse через Arenadata, почему выбрали именно такую топологию и какие нюансы появляются между кнопкой Install и действительно рабочим кластером. Мы разберём причины выбора такой схемы, увидим, где ADCM действительно упрощает эксплуатацию, какие мелочи всплывают вокруг SSH и Ansible и почему после успешного Install хост всё ещё может выглядеть «жёлтым». В конце — проверки со стороны самого ClickHouse и несколько вещей, которыми мы дополнили кластер уже после раскатки.

https://habr.com/ru/companies/rtlabs/articles/1088140/

#devops #ClickHouse #Arenadata #ADCM #ADQM #кластер #репликация #SSH_hostprovider #импортозамещение #отказоустойчивость

PostgreSQL 19 Beta 4: пять изменений, которые я бы проверил на staging до релиза

24 сентября вышла PostgreSQL 19 Beta 4. До release candidate осталось совсем немного, и на этом этапе уже интереснее смотреть не на длинный список новых возможностей, а на те изменения, которые реально способны поменять повседневную работу backend-команды. В релизе есть заметные вещи вроде REPACK , нового WAIT FOR LSN , параллельного autovacuum, репликации sequence и pg_plan_advice . Но почти у каждой из них есть важное «да, но». REPACK (CONCURRENTLY) не означает «VACUUM FULL без блокировок». WAIT FOR LSN не превращает асинхронную реплику в синхронную. Планировщик теперь можно подталкивать, но это не делает hint-ы хорошей идеей по умолчанию. Именно поэтому вместо обзора «50 новых фич PostgreSQL 19» я выбрал пять изменений, которые стоит прогнать на собственном staging до GA. Не чтобы немедленно включить их в production, а чтобы заранее понять, какие старые костыли после обновления можно будет убрать, а где появятся новые точки контроля.

https://habr.com/ru/articles/1087440/

#postgresql_19 #репликация #autovacuum #backend #highload #производительность

Где заканчивается автопилот в DR: разбор оркестрации ВМ, WORM в S3, конфликтов с СРК и задач DBA

Привет, Хабр! Разбирать вопросы после эфиров — полезная практика. В чате трансляции часто поднимают темы, с которыми инженерам приходится сталкиваться на пилотах и в продакшене. На вебинаре Хайстекс про восстановление в гибридной и мультиоблачной среде мы разбирали сценарии катастрофоустойчивости. Из обсуждения в чате получился список практических тем: оркестрация, гибридное хранение, защита от шифровальщиков и совместная работа с действующей СРК. Под катом разбор этих тем и линк на демо. Кат

https://habr.com/ru/companies/hstx/articles/1087352/

#вопросы_и_ответы #команда_разработки #разбор #аварийное_восстановление #disaster_recovery #репликация #failover #failback #oracle #s3

Четверо в одной транзакции: кейс-батлы, PgBouncer под Prisma и реплика, которая показывает пустой инвентарь

Обе мои предыдущие статьи про этот сайт с кейсами CS2 заканчивались списком того, чего в нём нет: платежей, депозита предметов, кейс-баттлов, рефералки, KYC. Список закрыт — и почти всё сложное в нём свелось к одному вопросу: что происходит, когда несколько человек одновременно двигают одни и те же деньги. Батл на четверых в одной транзакции, порядок блокировок, из-за которого не случается дедлок, PgBouncer под Prisma и правило чтения с реплики, которое нельзя выразить типом.

https://habr.com/ru/articles/1084056/

#postgresql #конкурентность #транзакции #дедлок #pgbouncer #prisma #репликация #кэширование #нагрузочное_тестирование #nestjs

Скопируй и спаси: как устроена репликация в TATLIN.BACKUP

Серьезное хранилище резервных копий не просто дедуплицирует данные и не теряет все при вылете одного диска — оно как минимум состоит из двух нод на случай, если одна сломается. Серьезное хранилище умеет делать снапшоты, чтобы злоумышленник не испортил всё, получив доступ к файловым шарам. У такого хранилища есть дедупликация на клиенте. А еще действительно серьезное хранилище умеет реплицировать данные на другую систему. Без всех этих опций индустрия просто не рассмотрит такое Purpose Built Backup Appliance как достойного кандидата занять вакантное место в стойке. Под катом я расскажу о репликации в TATLIN.BACKUP: зачем нужно, как работает, какие особенности есть.

https://habr.com/ru/companies/yadro/articles/1082128/

#дедупликация #репликация #tatlinbackup #tboost

Нужна ли вашей распределённой СУБД византийская отказоустойчивость?

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

https://habr.com/ru/articles/1083192/

#cft #bft #valkey #ретроспектива #распределенные_системы #базы_данных #субд #кворум #репликация #консенсус

Как мы разрешили чтение с реплик PostgreSQL — и почему шесть лет говорили «нет»

Меня зовут Кирилл Манин , я почти шесть лет работаю в команде SQL DBA и занимаюсь развитием платформы баз данных Авито . Почти всё это время к нам регулярно обращались разработчики микросервисов: «Можно нам читать с реплик?» и «Как подключиться к реплике для чтения?». Мы всегда отвечали одинаково: платформа не поддерживает чтение с реплик, и добавлять такую возможность мы пока не планируем. Недавно мы пересмотрели это решение. Чтобы понять, почему на это ушло столько времени, сначала нужно разобраться, какую роль реплики играли в нашей платформе и какие гарантии меняются, когда на них появляется пользовательская нагрузка.

https://habr.com/ru/companies/avito/articles/1081346/

#postgresql #репликация #DBA #базы_данных #PgBouncer #отказоустойчивость #масштабирование #высоконагруженные_системы

Как KupujemProdajem ищет по 5,6 миллиона объявлений примерно за 10 мс с помощью Manticore Search

Как крупнейшая площадка объявлений Сербии использует Manticore Search, чтобы искать по 5,6 миллиона активных объявлений примерно за 10 мс, обновлять индекс в реальном времени и готовиться к гибридному поиску.

https://habr.com/ru/articles/1076740/

#Manticore_Search #полнотекстовый_поиск #базы_данных #производительность #репликация #гибридный_поиск

Oracle → PostgreSQL без даунтайма: как мы перевозили терабайт банковской базы и где всё ломалось

Задача звучала как задача из учебника: перенести кредитный домен банка с Oracle на PostgreSQL. 70+ таблиц, чуть больше терабайта данных, 500–3000 RPS на чтение и 50–300 на запись в пике. Одно ограничение: система обслуживает клиентов и не может остановиться. Ни на ночь, ни на выходные, ни «на 15 минут на переключение». Эта статья — не туториал «как мигрировать за 10 шагов». Таких на Хабре десятки, и половина из них сводится к «запустите ora2pg». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «об этом мы узнали за неделю до переключения». Если вы планируете такую миграцию, читайте как чеклист. Если уже прошли — сверьте, сколько совпало. Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин и сами проблемы — настоящие.

https://habr.com/ru/articles/1074552/

#миграция_баз_данных #zero_downtime #cdc #apache_kafka #pgbouncer #highload #архитектура_бд #shadow_reads #репликация

Переполнение диска в БД: обзор сценариев и механизмов защиты

База данных — бизнес-критический компонент любой ИТ-инфраструктуры, поэтому вопрос обеспечения ее доступности и отказоустойчивости обычно находится в центре внимания. Однако, фокусируясь на отказоустойчивости, компании нередко недооценивают риск переполнения диска. При этом подобные ситуации могут оставаться незамеченными до полной остановки записи БД, например при заполнении отдельного раздела, где хранятся данные или WAL. Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.

https://habr.com/ru/companies/vk/articles/1066922/

#vk_cloud #databases #переполнение_диска #wal #репликация #мониторинг #алерты #автомасштабирование #readonly_режим #отказоустойчивость

Снапшот — это не бэкап, а бэкап — это не гарантия

Что на самом деле защищает наши данные? Снапшоты, которые создаются за секунды и позволяют мгновенно откатиться к предыдущему состоянию? Регулярные резервные копии, которые хранятся на отдельном хранилище? Или репликация, которая обеспечивает непрерывность работы даже при сбое площадки? Каждая из этих технологий решает свою задачу. Но бывает и такое, что снапшоты используют как бэкапы, бэкапы хранят вместе с основными данными, а репликацию считают полноценной заменой резервному копированию. В этой статье расскажем, почему снапшот — это вообще не бэкап, почему репликация не заменяет резервное копирование, какие требования предъявляются к современной системе защиты данных, и покажем, как эти принципы реализованы в связке VMmanager и RuBackup.

https://habr.com/ru/companies/ispsystem/articles/1064744/

#бэкап #резервное_копирование #репликация #виртуализация #снапшоты #itинфраструктура

Почему шины данных не всегда лучшее решение для синхронизации систем

При миграции из одной корпоративной системы в другую часто встает задача репликации данных. Например, при поэтапной замене ERP по методологии Parallel Running во время опытной эксплуатации пользователи работают в двух системах, которые оперируют идентичным набором данных. Если модели данных сильно отличаются, а при репликации присутствует дополнительная логика, то команды чаще всего пытаются использовать шины данных (например Kafka). При таком подходе требуется самостоятельно реализовать механизмы копирования данных, обработки конфликтов, пересинхронизации, мониторинга и т. д. Все это увеличивает трудозатраты и потенциально может стать источником проблем. В этой статье разберем техническую реализацию репликации данных через шины, ее слабые места, а также альтернативные подходы.

https://habr.com/ru/companies/haulmont/articles/1058574/

#erpсистемы #миграция #миграция_данных #синхронизация #синхронизация_данных #репликация #репликация_данных #parallel_running #erp #шины_данных

Шардинг в Manticore Search: автоматическое распределение и репликация

На старте поисковая система часто устроена просто: одна таблица на одном сервере. Это работает, пока не случится одно из двух. Либо отдельный запрос перестаёт задействовать весь CPU, за который вы заплатили, либо одного сервера перестаёт хватать — по объёму, по пропускной способности или просто потому, что сервер может выйти из строя, и данные на нём будут потеряны. Автоматический шардинг, встроенный в Manticore Search и доступный начиная с релиза 27.1.5 , решает обе проблемы, разбивая таблицу на несколько физических фрагментов меньшего размера (шардов), по которым можно выполнять поиск параллельно и которые можно размещать на разных узлах :

https://habr.com/ru/articles/1055064/

#шардинг #шардирование #высокая_производительность #масштабирование_систем #масштабирование_поиска #распределение_данных #кластер #репликация #балансировка_нагрузки

Проблема миграции больших кластеров на Cassandra

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

https://habr.com/ru/companies/dbraincloud/articles/1053998/

#cassandra #базы_данных #база_дынных #миграция #snapshot #кластер #репликация #kubernetes #statefulset #оператор

С самого начала у нас был четкий план восстановления, и мы его придерживались: как рассчитать честные RTO и RPO

Классическая ловушка при проектировании отказоустойчивости — разрыв между ожиданиями бизнеса и возможностями инфраструктуры. На бумаге в SLA может быть зафиксировано RTO в 4 часа, но если терабайтный бэкап PostgreSQL физически разворачивается 8 часов из-за лимитов дисковой подсистемы, такой SLA не выдержит первого серьезного инцидента. На практике планы Disaster Recovery (DR) часто пишутся «для галочки» и в полном отрыве от реальной архитектуры. Под катом — техническая изнанка проектирования отказоустойчивости: как приземлить RTO и RPO на реальную инфраструктуру, связать их со стоимостью простоя и взять эти метрики под контроль с помощью правильных инженерных подходов. Также в статью включены практические инструменты: пошаговый чек-лист для безопасного проведения DR-учений и перечень ключевых параметров, которые необходимо непрерывно мониторить для контроля рисков. Кат

https://habr.com/ru/companies/hstx/articles/1054008/

#RTO #RPO #Disaster_Recovery #DRaaS #PostgreSQL #отказоустойчивость #бэкап #репликация #SLA #Хайстекс_Акура

[Перевод] Как Reddit без потерь перенес петабайтную Kafka с EC2 на Kubernetes

Миграция — риск даже для небольших инфраструктур. А когда у вас больше миллиарда пользователей и петабайт данных, права на ошибку нет вообще. Но выход всё равно один — грамотно спланировать переезд и... взять и сделать. В статье — о том, как Reddit перешёл на Kubernetes: почему они отказались от Amazon EC2, какие ограничения им пришлось учитывать и чем их опыт может быть полезен в других проектах.

https://habr.com/ru/companies/flant/articles/1043518/

#kafka #миграция #strimzi #reddit #kraft #kubernetes #ec2 #zookeeper #репликация

Почему ваш DR-план не сработает при реальной аварии (и что с этим делать)

Недавно на вебинаре Хайстекс разбирались реальные сценарии DR на практике. В чате трансляции зрители задали ряд технических вопросов, наиболее интересные из них легли в основу этого разбора.

https://habr.com/ru/companies/hstx/articles/1048140/

#аварийное_восстановление #disaster_recovery #RTO #RPO #репликация #failover #failback #резервное_копирование #виртуализация #хайстекс_акура

Три задачи discovery при работе с PostgreSQL master/replica — и как их решить

Когда у приложения появляется несколько хостов PostgreSQL, начинается головная боль: нужно динамически находить мастера после failover, выбирать реплику с нужным отставанием и гарантировать что пользователь не увидит устаревшие данные после своей же записи. DNS кешируется минутами, libpq не знает про lag, HAProxy не слышал про LSN. Разбираем как устроены существующие решения и как закрыть все три задачи через лёгкий HTTP сервис — pg-status .

https://habr.com/ru/articles/1047374/

#postgresql #репликация #failover #replication #python #sql #discovery #high_availability

[Перевод] MariaDB 12.3: binlog внутри InnoDB

Коротко для ленивых В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb . Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency. В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x . Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения. Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo. Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.

https://habr.com/ru/articles/1011298/

#MariaDB_123 #InnoDB #binlog #GTID #репликация #производительность_SQL #crash_recovery #fsync #OLTP

Как мы нашли своё решение для миграции и репликации данных в РСХБ

Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна. Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке.В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.

https://habr.com/ru/companies/rshb/articles/1010760/

#CDCрешение #импортозамещение #Postgess #репликация #миграция_данных #sql #lowcode

Как мигрировать кусочек Яндекс Такси с PostgreSQL на YDB (СУБД Яндекса) и перестать считать подключения к шардам

Привет, Хабр! Меня зовут Игорь Березняк, и мы с командой делаем Техплатформу Городских сервисов Яндекса. Я уже писал на Хабре про архитектуру платформы, рассказывал на «Хайлоаде» (и на Хабре ) про шардирование и миграцию на YDB . Эта статья написана по мотивам последнего доклада. В ней я рассказываю не о самой миграции (ну мигрировали и мигрировали, этим сейчас никого не удивишь), а о её причинах. Дело в том, что PostgreSQL — потрясающая система. Инженерное чудо, позволяющее сейчас нескольким разработчикам собирать системы, для которых всего пару десятков лет назад потребовалась бы команда архитекторов и контракт с вендором. Но, разрабатывая любую систему, программисты пишут код, который лучше всего работает в ожидаемых сценариях. Эта статья о том, с какими ограничениями PostgreSQL сталкиваются системы масштаба Яндекс Такси при росте. Я расскажу про время выбора нового мастера при репликации, лимиты количества соединений, разработку холодного хранилища. В моём рассказе переход на YDB — это в первую очередь смена одних ожидаемых сценариев работы на другие. Со своими последствиями, компромиссами, необходимостью адаптировать и переписывать код.

https://habr.com/ru/companies/ydb/articles/1001532/

#ydb #postgresql #репликация #шардирование #highload

Механизмы репликации в РЕД АДМ «под капотом». Разбираемся в логике и процессах

Привет, Хабр! На связи снова Дмитрий, инженер по инфраструктурным решениям РЕД СОФТ. В прошлой статье мы разбирали, как настроить службу каталогов РЕД АДМ в ручном режиме, а также рассматривали самые распространённые ошибки в этом процессе. А в сегодняшней статье я постараюсь дать ответ, пожалуй, на весьма сложный вопрос — как работает репликация в РЕД АДМ «под капотом». Эта статья — больше технический обзор, чем какой-либо чек-лист или инструкция. Мы дотошно пройдёмся по каждому этапу репликации. Я расскажу, что означают сообщения в терминале и подскажу, как на них реагировать. Материал будет интересен всем, кто хочет разобраться во внутренних процессах репликации: её логике, командах и функциях.

https://habr.com/ru/companies/redsoft/articles/980356/

#microsoft_acrive_directory #ред_адм #миграция_итинфраструктуры #контроллер_домена #импортозамещение #редсофт #репликация #домен #redsoft #руссофт

Patroni и логическая реплика в PostgreSQL: как не потерять данные при failover’е

Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.

https://habr.com/ru/companies/flant/articles/978322/

#patroni #postgresql #sql #бд #failover #репликация #асинхронная_репликация #логическая_репликация #nofailover #потеря_данных

Как защитить сервисы от вирусов-шифровальщиков при помощи MIND Guard #guest

“ Администраторы делятся на три категории - тех, кто еще не делает бекапы, тех, кто уже делает, и тех, кто уже проверяет бекапы. ” Когда речь заходит о необходимости защиты данных сервисов и приложений, на ум в первую очередь приходит резервное копирование и репликация. Наличие копии вселяет ложное чувство уверенности: «у нас есть копия = мы в безопасности». Здесь кроется ловушка: резервное копирование позволяет восстановиться после сбоев, которые легко распознать, например, от физических отказов - выхода из строя диска, случайного удаления тома, сбоя узла.

https://habr.com/ru/companies/mind_software/articles/971392/

#MIND_Suite #MIND_Guard #вирусышифровальщики #целостность_данных #защита_данных #защита_сервисов #Репликация #отказоустойчивость #катастрофоусточивая_защита

Понимание и практические эксперименты с Tablet в StarRocks

внутренняя структура, репликации и балансировка, бакетизация и партиционирование, восстановление и MVCC, загрузка данных (Stream Load). Разбираем типичные сценарии и даём рекомендации для Data Engineers и DBAs.

https://habr.com/ru/articles/970880/

#StarRocks #Tablet #OLAP #MPP #репликация #балансировка #бакетизация #партиционирование #MVCC #Stream_Load

Обзор Moco — MySQL-оператора для Kubernetes

В Kubernetes короткий жизненный цикл подов — норма. Но когда лидер-узел MySQL внезапно исчезает, рискуешь потерять не только доступность, но и согласованность данных. Оператор Moco предлагает решение: полусинхронная репликация, автоматический failover и восстановление с PITR — всё это без боли миграции на полностью синхронную репликацию. В статье — детали репликации, бэкапов, PITR, switchover и нюансов работы с пользовательскими образами. А также честно — чем он лучше (и хуже) альтернатив, и стоит ли его рассматривать для продакшена.

https://habr.com/ru/companies/flant/articles/969520/

#moco #sql #MySQLоператор #mysql #Полусинхронная_репликация #репликация #MySQLкластер #согласованность_данных #gtid

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

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

https://habr.com/ru/companies/hstx/articles/949622/

#хранилище #хранилище_данных #хранилище_медицинских_данных #бэкап #восстановление_данных #репликация #rto #отказоустойчивость

[Перевод] Облачные вычисления в 2025 году: рост ИИ приводит к революции на рынке объемом $723 млрд

Перевод статьи Патрика Косса о том, как ИИ, edge-компьютинг, serverless и мультиоблачные стратегии меняют облачную инфраструктуру. Автор подчеркивает, что речь идет не о постепенной эволюции, а о настоящей трансформации, которая уже влияет на стратегию крупнейших компаний и задаёт новые правила игры. Индустрия облачных вычислений переживает свой самый трансформационный период: интеграция искусственного интеллекта стимулирует беспрецедентный рост и меняет то, как компании подходят к цифровой инфраструктуре. Новые данные показывают, что глобальные расходы на публичные облачные сервисы достигнут $723,4 млрд в 2025 году, что составляет рост на 21% по сравнению с $595,7 млрд в 2024 году. Этот всплеск связан с тем, что всё больше организаций обращаются к облачным сервисам с поддержкой ИИ: уже 72% компаний используют платформы генеративного ИИ, и эта тенденция кардинально меняет распределение ресурсов и стратегические приоритеты в разных отраслях.

https://habr.com/ru/companies/hstx/articles/947190/

#хранилище #хранилище_данных #бэкап #восстановление_данных #репликация #rto #отказоустойчивость #облако #edge #serverless

Никакого наития, только полный контроль. Как построить эффективную стратегию бэкапа с Хайстекс Акура и S3-хранилищем

Привет Хабр! Меня зовут Юлия Воробьева, и уже больше 10 лет я занимаюсь тестированием. За это время успела поработать в проектах, связанных с восстановлением, миграцией и резервным копированием данных. Я много занимаюсь облачными технологиями и получаю от этого настоящее удовольствие. Последние 6 лет я работаю в компании Хайстекс, где продукт и задачи позволяют мне не просто тестировать, а прокачивать экспертизу и при этом сохранять интерес к облачным решениям. В этой статье расскажу, как мы настроили, внедрили и протестировали резервное копирование с решением Хайстекс Акура и S3-хранилищем от Selectel, на основе реальных требований и возможностей компании-клиента. Покажу, как это выглядит на практике глазами QA. Не претендую на универсальный рецепт, но подробно опишу, как мы упростили восстановление тестовой среды, сэкономили время и перестали бояться, что важные данные потеряются после очередного сбоя. Разберу всё по шагам: как настраивали, что сработало, где пришлось доработать и какие выводы сделали в итоге. Если вам интересно, как внедрить надежный бэкап всех данных у себя в компании, встретимся под катом. Там же ссылка на вебинар для тех, кому ближе видеоформат. Разбор по шагам

https://habr.com/ru/companies/hstx/articles/940504/

#хайстекс #акура #s3_хранилище #бэкап #selectel #восстановление_данных #репликация #rto #отказоустойчивость #облако

Развёртывание боевого кластера Cassandra. Часть 3

Это продолжение цикла, рассказывающего о практике развёртывания небольшого, но вполне производственного кластера Cassandra. В первой и второй частях мы продвинулись вперед вот по такому плану: 1. Анализ рабочей нагрузки и требований 2.Разработка схемы данных 3. Настройка хостовых машин 4. Настройка конфигурации Cassandra = ВЫ НАХОДИТЕСЬ ЗДЕСЬ = 5. Настройка топологии кластера 6. Подключение Prometheus Cassandra Exporter 7. Подключение Prometheus Node Exporter 8. Вывод всех метрик в Grafana 9. Проведение нагрузочного тестирования 10. Дополнительный тюнинг по результатам теста Двинемся дальше?

https://habr.com/ru/articles/940268/

#cassandra #базы_данных #инфраструктура #highload #топология #кластер #репликация #консистентность #балансировка_нагрузки #devops