Мы уже изучали репликацию и масштабируемость, а затем давайте рассмотрим удобство использования. В конечном счете, высокая доступность означает “меньшее время простоя”.
Старое правило, обсуждая существительное, прежде всего, чтобы определить его, тогда что такое удобство использования?
1 Что такое доступность
Наше общее удобство использования обычно выражается в процентах, что само по себе имеет скрытый смысл: Высокая доступность не является абсолютной . Другими словами, 100% доступность невозможна. Да, здесь я могу сказать с уверенностью.
Удобство использования обычно описывается числом “9”. X 9 показывает отношение обычного времени использования каждой системы к общему времени использования (1 год) в течение одного года работы центра обработки данных. Например, “5 9” означает 99,999%, затем применяется время простоя время t:
(1-99.999%) 3600 24 *.36с.256м
Таким образом, мы можем сказать, что “5 9” означает, что приложение допускает только 5,256 минут простоя в год. По тем же расчетам мы можем сделать вывод, что время простоя в течение трех девяти лет составляет 8,76 часа, а в течение четырех девяти лет-52,6 минуты.
На самом деле, 5 9 уже очень сложно для большинства приложений, но для некоторых крупных компаний они, безусловно, попытаются получить больше 9, что позволило свести к минимуму время простоя и снизить затраты на время простоя.
Требования к доступности различаются для каждого приложения. Прежде чем устанавливать целевое значение, важно рассмотреть, действительно ли оно должно быть достигнуто. Эффект доступности и доля расходов не увеличиваются линейно. Каждое небольшое увеличение доступности обходится намного дороже, чем раньше.
Поэтому для удобства использования мы можем следовать такому принципу:
Сколько времени простоя может быть потрачено, можно гарантировать соответствующее доступное время. 。
Это может быть немного странно. Проще говоря: для приложений с пользователями мощностью 10 Вт, предполагая, что для реализации 5 9 требуется 100 Вт, а общая потеря составляет всего 50 Вт, даже если приложение отключается на 9 часов каждый год, считаете ли вы, что для этого приложения необходимо обеспечить доступность 5 9?
Кроме того, мы определили удобство использования как “время простоя” выше, но на самом деле удобство использования должно быть В том числе, может ли приложение обрабатывать запросы с достаточной производительностью . Для большого сервера перезапуск MySQL может занять несколько часов, чтобы разогреть данные, чтобы обеспечить время ответа на запрос. Часы здесь также должны быть включены в время простоя.
До сих пор у нас должно сложиться общее впечатление, что удобство использования связано с простоем приложений. Далее давайте сделаем еще один шаг, чтобы понять причины простоя.
2. Причины простоя
Возможно, самая распространенная причина, по которой мы слышим о простоях базы данных, заключается в том, что Производительность SQL низкая . На самом деле это не так. В зависимости от причин простоя, вызванного способом выражения, его можно разделить на следующие категории:
| 35% | Исчерпание дискового пространства | Операционная среда |
| 35% | 1. Низкая производительность SQL; 2. ОШИБКА сервера; 3. Плохой дизайн структуры таблиц и дизайн индексов | Проблемы с производительностью |
| 20% | Несоответствие первичных и резервных данных | копировать |
| 10% | Неправильное использование, удаление данных, отсутствие резервной копии | Потеря или повреждение данных |
Рабочую среду обычно можно рассматривать как набор системных ресурсов, поддерживающих работу сервера баз данных, включая операционную систему, жесткий диск и сеть.
Кроме того, хотя мы часто используем репликацию для увеличения доступного времени, она также является одним из важных “виновников”, приводящих к простою. Это также иллюстрирует общую ситуацию:
Многие стратегии высокой доступности могут привести к обратным результатам
Понимая определение удобства использования и факторы, которые его снижают, нам необходимо рассмотреть вопрос о том, как улучшить удобство использования системы.
3 Как добиться высокой доступности
Из приведенного выше анализа вы, возможно, обнаружили, что наша доступность зависит от двух раз:
- Среднее время отказа приложения
- Среднее время восстановления приложения
Поэтому улучшение удобства использования также может начинаться с этих двух аспектов. Во-первых, время простоя можно свести к минимуму, избегая простоев. На самом деле, многих проблем с простоем можно легко избежать с помощью надлежащей конфигурации, мониторинга и мер регулирования или безопасности.
Во-вторых, постарайтесь обеспечить, чтобы при возникновении простоя он мог быстро восстановиться. Наиболее распространенной стратегией является создание избыточности в системе и обеспечение возможности отработки отказа системы.
Далее давайте познакомимся с конкретными мерами.
3.1 Сокращение среднего времени отказа
Нам не хватает управления системными изменениями Это наиболее распространенная причина всех простоев. Типичные ошибки включают небрежное обновление, приводящее к неудачным обновлениям и обнаруженным ошибкам, или выполнение изменений в структурах таблиц данных или операторах запросов непосредственно в Интернете без тестирования, или невыполнение плана на случай сбоев, таких как превышение предельной емкости диска.
Еще одной серьезной причиной простоев является отсутствие тщательной оценки. Например, из-за небрежности не подтверждено, можно ли восстановить резервную копию.
Существует также вероятность того, что отсутствует точный мониторинг информации, связанной с MySQL. Например, тревога о частоте попадания в кэш может быть только ложной тревогой, которая не указывает на наличие проблемы. В результате мы считаем, что система мониторинга бесполезна, и игнорируем реальную проблему тревоги. Босс спросил вас, почему диск был заполнен, и вы невинно посмотрели на него, когда не получили тревожное сообщение.
Поэтому, пока мы выполняем более целенаправленную работу, мы можем избежать большого количества простоев. В частности, могут быть приняты следующие меры:
- Протестируйте инструменты и процессы восстановления, включая восстановление данных из резервных копий.
- Соблюдайте принцип минимальных полномочий.
- Содержите систему в чистоте и порядке.
- Используйте правильные названия и организационные соглашения, чтобы избежать путаницы. Например, используется ли сервер для разработки или производственных сред?
- Тщательно подготовьтесь к обновлению сервера базы данных.
- Перед обновлением используйте такие инструменты, как pt-upgrade в Percona Toolkit, чтобы тщательно изучить систему.
- Используйте InnoDB и настройте его соответствующим образом, чтобы гарантировать, что InnoDB является механизмом хранения по умолчанию. Если механизм хранения отключен, сервер не может запуститься.
- Проверьте правильность базовой конфигурации сервера.
- DNS запрещен решением skip_name_resolution.
- Кэширование запросов следует отключить, если неясно, полезно ли кэширование запросов.
- Избегайте использования сложных функций, если они вам действительно не нужны. Например, фильтрация копирования, триггеры и т. Д.
- Контролируйте важные компоненты и функции. Особенно ключевые проекты, такие как дисковое пространство и состояние тома RAID 。
- Записывайте состояние сервера и показатели производительности как можно дольше.
- Регулярно проверяйте целостность репликации.
- Будет намеренно настроено только для чтения, не позволяйте копированию запускаться автоматически.
- Периодически просматривайте инструкции запроса.
- Файл и очистите ненужные данные.
- Зарезервируйте немного свободного места для файловой системы;
- Выработайте привычку оценивать и управлять изменениями, информацией о состоянии и производительности системы.
3.2 Сокращение среднего времени восстановления
Что касается времени восстановления, мы можем начать с трех аспектов:
- Чтобы создать избыточность для системы, убедитесь в возможности отработки отказа системы и избегайте одноточечного сбоя.
- Разработайте полную спецификацию процесса восстановления для персонала.
- Организуйте посмертное повторное предложение для персонала, чтобы избежать подобных ошибок в будущем.
Далее давайте обсудим конкретные меры.
1) Как избежать одноточечного сбоя?
При одноточечном сбое первое, что нам нужно сделать, – это найти его, а затем соответствующим образом решить.
В системе каждая отдельная точка может выйти из строя. Это может быть жесткий диск, сервер, коммутатор, маршрутизатор или даже источник питания в стойке и т. Д.
Прежде чем принимать соответствующие меры, мы должны понимать, что одноточечный сбой не может быть полностью устранен. Мы можем внедрять новые технологии для решения проблемы одноточечного отказа, но внедрение новых технологий может привести к большему количеству простоев. Поэтому мы должны ранжировать единственную точку отказа в соответствии с уровнем воздействия и решать проблему с одним отказом в соответствии с ранжированием.
В частности, есть два способа увеличить избыточность: Увеличить запасную емкость и Повторяющиеся компоненты .
Увеличить запасную мощность относительно просто. Вы можете создать кластер или пул серверов, используя схему балансировки нагрузки. Таким образом, когда один сервер выходит из строя, другие серверы могут взять на себя нагрузку вышедшего из строя сервера.
Кроме того, во многих аспектах рассмотрения могут потребоваться резервные компоненты, может произойти отказ основного компонента, может потребоваться замена запасной части в любое время. Резервными компонентами могут быть неработающие сетевые карты, маршрутизаторы или жесткие диски.
Кроме того, самое главное-это полностью резервные серверы MySQL. Это означает, что мы должны убедиться, что резервный сервер имеет доступ к данным на основном сервере. Могут быть приняты следующие меры:
- Совместное хранилище или репликация на диске
- Синхронная репликация MySQL
2) Как обеспечить отказоустойчивость и возможность восстановления системы?
Прежде чем мы начнем эту тему, давайте сначала поймем, что такое “отказоустойчивость”. Некоторые люди используют “отступить”, чтобы указать на запланированное переключение, а не на реакцию после сбоя.
Здесь мы используем “отработка отказа” для обозначения обратного отработки отказа. Если система имеет возможность восстановления неисправностей, то передача неисправностей-это двусторонний процесс:
Когда сервер A выходит из строя, сервер B заменяет его и может быть заменен после ремонта сервера A.
Наиболее важной частью отработки отказа является восстановление после отказа. Если нет свободного переключения между серверами, отказоустойчивость является тупиковой и только задерживает время простоя. Поэтому при использовании репликации можно использовать симметричный макет репликации, такой как двойная основная структура. Поскольку конфигурация одинакова, отработка отказа и восстановление-это одни и те же операции в противоположном направлении.
Далее мы рассмотрим некоторые из наиболее распространенных технологий отработки отказа.
Обновление резервных или Переключение ролей
Продвижение резервной копии в качестве основной библиотеки или изменение активных и пассивных ролей в структуре репликации мастер-мастер являются важными частями многих стратегий отработки отказа MySQL. См. Раздел Репликация MySQL – краеугольный камень производительности и расширяемости 4. переключение между основным и резервным репозиториями
Виртуальный IP-адрес или захват IP-адреса
Вы можете указать логический IP-адрес для экземпляров MySQL, которым необходимо предоставлять службы функций. Когда экземпляр MySQL выходит из строя, IP-адрес передается на другой сервер MySQL. Решение здесь, по сути, является той же технологией виртуального IP в балансировке нагрузки, но разница в том, что теперь она используется для отработки отказа.
Преимущество этого метода заключается в том, что он прозрачен для приложения. Это прерывает существующие соединения, но не требует изменения конфигурации.
Конечно, у него также есть некоторые недостатки:
- Все IP-адреса должны быть определены в одном и том же сегменте, или используется сетевое соединение.
- Иногда вам нужно обновить кэш ARP. Некоторые сетевые устройства могут хранить информацию ARP слишком долго, что приводит к невозможности немедленного переключения IP-адреса на другой MAC-адрес.
- Необходимо определить, поддерживает ли сетевое оборудование быстрое переключение IP-адресов. Некоторым аппаратным средствам необходимо клонировать MAC – адрес, прежде чем он сможет работать.
3) Как члены команды могут улучшить время восстановления системы?
Поскольку у каждого сотрудника в команде разная квалификация и соответствующие способности для восстановления простоев, нам также нужна спецификация процесса для соответствующего персонала, чтобы помочь всем участвовать в простоях и сократить время восстановления системы.
После восстановления системы нам нужно организовать людей для оценки простоя. Здесь мы должны обратить внимание на то, чтобы не ожидать слишком много “запоздалых мыслей” такого рода. Существует множество причин простоя. Нам трудно проанализировать ситуацию с проблемой в то время и найти реальную причину. Поэтому у нас должны быть некоторые оговорки в отношении выводов, которые мы сделаем из нашего последующего размышления.
4 Краткое изложение
- Удобство использования измеряется временем простоя от n до 9.
- Реализация доступности с Среднего времени сбоя и Среднего времени восстановления 。