Архитектура с главной и несколькими подчиненными базами данных

Более целенаправленный и агрессивный метод определения потолков базы данных заключается в медленном (и, более того, осторожном!) повышении нагрузки на «живой» сервер. Если в вашем ведении находится всего одна база данных, сделать это без ущерба для безопасности будет непросто. С единичной точкой отказа вы рискуете полностью вывести сайт из строя. Задача существенно упрощается при использовании любой разновидности распределения нагрузки (аппаратного или прикладного уровня). На рисунке снова представлена диаграмма типичной архитектуры базы данных с добавлением некоторых реалистичных подробностей.

В этой архитектуре все операции записи направляются в главную базу данных; операции чтения выполняются с подчиненными базами. Информация в подчиненных базах данных обновляется посредством репликации. Чтобы определить потолки подчиненных баз данных, следует увеличивать нагрузку на одной из них, приказав балансировщику отдавать предпочтение этому конкретному устройству. Если вы используете аппаратный балансировщик нагрузки, назначьте одному из серверов более высокий приоритет по сравнению с другими серверами пула.

Повышение нагрузки на базу данных может показать, как нагрузка влияет на ваши ресурсы, а возможно, и выявить точку, в которой нагрузка начинает влиять на задержку репликации. В нашей ситуации хотелось бы подтвердить обоснованное предположение о том, что 40-процентное ожидание дискового ввода/вывода определяет верхний предел, который база данных может выдержать без образования задержки репликации.

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