HighLoad_HomeWork/test/dz003/README.md

38 lines
3.4 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

#ЗАЧТЕНА: [ЧАТ](https://otus.ru/learning/61597/#/homework-chat/12339/) / [ОТЧЕТ](REPORT.md)
-----
#Полусинхронная репликация
В результате выполнения ДЗ вы настроите полусинхронную репликацию, протестируете ее влияние на производительность системы и убедитесь, что теперь вы не теряете транзакции в случае аварии.
### В данном задании тренируются навыки:
- обеспечение отказоустойчивости проекта;
- администрирование MySQL;
- настройка репликации;
- проведение нагрузочных тестов.
### План выполнения ДЗ:
1) Настраиваем асинхронную репликацию.
2) Выбираем 2 любых запроса на чтения (в идеале самых частых и тяжелых по логике работы сайта) и переносим их на чтение со слейва.
3) Делаем нагрузочный тест по странице, которую перевели на слейв до и после репликации. Замеряем нагрузку мастера (CPU, la, disc usage, memory usage).
4) ОПЦИОНАЛЬНО: в качестве конфига, который хранит IP реплики сделать массив для легкого добавления реплики. Это не самый правильный способ балансирования нагрузки. Поэтому опционально.
5) Настроить 2 слейва и 1 мастер.
6) Включить row-based репликацию.
7) Включить GTID.
8) Настроить полусинхронную репликацию.
9) Создать нагрузку на запись в любую тестовую таблицу. На стороне, которой нагружаем считать, сколько строк мы успешно записали.
10) С помощью kill -9 убиваем мастер MySQL.
11) Заканчиваем нагрузку на запись.
12) Выбираем самый свежий слейв. Промоутим его до мастера. Переключаем на него второй слейв.
13) Проверяем, есть ли потери транзакций.
Результатом сдачи ДЗ будет в виде исходного кода на github и [отчета в текстовом виде](REPORT.md), где вы отразите как вы выполняли каждый из пунктов.
Критерии оценки: Оценка происходит по принципу зачет/незачет.
### Требования:
- В отчете корректно описано, как настроена репликация.
- 2 запроса переведено на чтение со слейва.
- Нагрузочное тестирование показало, что нагрузка перешла на слейв.
- В отчете описано как включить row-based репликацию и GTID
- Проведен эксперимент по потере и непотере транзакций при аварийной остановке master.