Метка «replication»

Недавно мне поставили такую задачу: Есть много коммивояжеров с ноутбуками которые разъезжают по стране и что-то кому-то впаривают продают.
Т.к. им нужны актуальные данные о наличии товара и ценах, время от времени они подключаются к центральному серверу через интернет и сливают себе обновленные данные.

Условия к задаче:
— Частота и периодичность выхода на связь коммивояжеров неизвестна, ровно как и дилтельность.
— Должно все работать максимально надежно, потому как коммивояжеры они такие «коммивояжеры».
— Решение должно быть на базе Mysql master-slave replication.

Выводы из условия:

— Для надежности, на стороне клиента(slave) минимум настроек, никаких скриптов по крону, все должно быть внутри mysql.
— Т.к. неизвестно когда и с какой периодичностью будут подключаться к master базе коммивояжеры, binlog на мастере нужно хранить так долго пока все slave не скачают его себе.

Решение:
— Информировать мастер, какие slave и сколько уже «скачали». А точнее в какой позиции самый «ленивый» slave.
— Все остальные binlog можно смело удалять.

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

Привет сообщество! image

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

AWS RDS MySQL предлагает такое решение, так сказать, «из коробки». В консоли или через CLI (API) вам предлагается создать реплику. Что же происходит «под капотом»?

  1. Создаётся образ существующего сервера. Эта операция может повлиять на I/O, как вы понимаете. Не стоит делать образ в загруженные часы.
  2. Из образа стартует новый инстанс, который конфигурится и становится репликой в режиме «только чтение» — RO.

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

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

Основных причин этому две:

  1. Нагрузочные тесты показали приличное снижении скорости записи в режиме кластера
  2. В среднем каждые 2-3 дня я ловлю новый глюк, причины которого не всегда удается осмыслить и приходится заново инициализировать кластер.

Справедливости ради отмечу, что некоторые глюки возникают совсем на другом уровне, например в слое балансировки нагрузки или утилите xtrabackup. Но о глюках в другой раз, а в этой заметке я остановлюсь на проблеме из п. 1 и попробую резюмировать главное из того, что я узнал о накладных расходах в Galera репликации и о способах минимизировать потерю производительности, связанную с ними. Читать полностью »

    В статье ниже я попытаюсь кратко рассказать о том, что такое TarantoolBox и как начать его использовать в уже существующем проекте если вы программируете на Java. Если же вы программируете на другом языке, то вам могут быть интересны некоторые инструменты доступные в коннекторе, такие как возможность редактирование xlog файлов и создание snap файлов из любых данных.
Читать полностью »

    В статье ниже я попытаюсь кратко рассказать о том, что такое Tarantool и как начать его использовать в уже существующем проекте если вы программируете на Java. Если же вы программируете на другом языке, то вам могут быть интересны некоторые инструменты доступные в коннекторе, такие как возможность редактирование xlog файлов и создание snap файлов из любых данных.
Читать полностью »

За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это «золотое» правило всех администраторов баз данных – не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. – то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени.

Недавно перед нами была поставлена задача – разработать процедуру резервного копирования хранилища данных размером в 20 Терабайт. Используя наработанные практики резервного копирования, я попытался разработать такую процедуру и уложиться в то же время в рамки RPO (recovery point objective) и RTO (recovery time objective). Обе эти характеристики измеряются во времени и представляют собой следующее: RPO – допустимый объем возможных потерь данных, RTO – допустимое время простоя или за какое время база данных должна восстановиться. Вот тут-то и началось самое интересное – как бы я не прикидывал и не рассчитывал, но разработанная процедура резервного копирования никак не желала укладываться в эти рамки – слишком большой объем данных надо было забэкапить. В самом лучшем случае, с многочисленными оговорками и условиями база данных восстанавливалась за несколько часов, а такого бизнес себе позволить не мог. Хотя, у Сбербанка на этот счет несколько иное мнение и они считают, что клиенты могут и подождать. Но тут был не Сбербанк. В обычной же ситуации, когда на базу данных не налагались серьезные ограничения и условия, восстановление заняло бы несколько дней. Это усугублялось тем, что невозможно «снять» бэкап за приемлемое время – это также занимало несколько дней и создавало большую нагрузку на базу данных. Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии. Возможно, если бы мы могли получить инкрементальность, то игра и стоила бы свеч, и традиционная процедура резервного копирования имела бы право на жизнь в этом случае.

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

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

Какие проблемы может помочь решить этот пост?

  • Что делать если у вас в списке процессов множественные селекты которым казалось бы никто не мешает?
  • Что делать если всё хорошо настроено, запросы пролетают как ракеты и список процессов постоянно пустой, но на сервере высокий LA и запросы начинают работать немного медленнее, ну например вместо 100мс получается 500мс ?
  • Как быстро масштабировать систему, когда нет возможности всё переделать?
  • У вас коммерческий проект в конкурентной среде и проблему надо решать немедленно?
  • Почему один и тот же запрос работает то быстро то медленно?
  • Как организовать быстрый кеш и поддерживать его в актуальном состояние?

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

Эволюция архитектуры: от «самописных» сервисов к HandlerSocket

Сегодня мы расскажем о том, как в Badoo изменился подход к проектированию нагруженных “key-value” сервисов. Вы узнаете, по какой схеме такие сервисы создавались нами несколько лет назад (использование БД в качестве репозиториев и специализированного демона как интерфейса к данным), с какими трудностями мы при этом столкнулись и к какой архитектуре в результате пришли, разрешив появившиеся проблемы.
Читать полностью »

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

image

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

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

О Чем Стоит Задуматься, Сохраняя Свои Данные в Облаке. Часть 1

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js