|
||
---|---|---|
.. | ||
img | ||
scripts | ||
README.md | ||
REPORT.md | ||
dz003.sh |
README.md
#Полусинхронная репликация
В результате выполнения ДЗ вы настроите полусинхронную репликацию, протестируете ее влияние на производительность системы и убедитесь, что теперь вы не теряете транзакции в случае аварии.
В данном задании тренируются навыки:
- обеспечение отказоустойчивости проекта;
- администрирование MySQL;
- настройка репликации;
- проведение нагрузочных тестов.
План выполнения ДЗ:
- Настраиваем асинхронную репликацию.
- Выбираем 2 любых запроса на чтения (в идеале самых частых и тяжелых по логике работы сайта) и переносим их на чтение со слейва.
- Делаем нагрузочный тест по странице, которую перевели на слейв до и после репликации. Замеряем нагрузку мастера (CPU, la, disc usage, memory usage).
- ОПЦИОНАЛЬНО: в качестве конфига, который хранит IP реплики сделать массив для легкого добавления реплики. Это не самый правильный способ балансирования нагрузки. Поэтому опционально.
- Настроить 2 слейва и 1 мастер.
- Включить row-based репликацию.
- Включить GTID.
- Настроить полусинхронную репликацию.
- Создать нагрузку на запись в любую тестовую таблицу. На стороне, которой нагружаем считать, сколько строк мы успешно записали.
- С помощью kill -9 убиваем мастер MySQL.
- Заканчиваем нагрузку на запись.
- Выбираем самый свежий слейв. Промоутим его до мастера. Переключаем на него второй слейв.
- Проверяем, есть ли потери транзакций.
Результатом сдачи ДЗ будет в виде исходного кода на github и отчета в текстовом виде, где вы отразите как вы выполняли каждый из пунктов. Критерии оценки: Оценка происходит по принципу зачет/незачет.
Требования:
- В отчете корректно описано, как настроена репликация.
- 2 запроса переведено на чтение со слейва.
- Нагрузочное тестирование показало, что нагрузка перешла на слейв.
- В отчете описано как включить row-based репликацию и GTID
- Проведен эксперимент по потере и непотере транзакций при аварийной остановке master.