Узнайте об архитектуре высокой доступности базы данных

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

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

Активная и резервная архитектура

1. Топология базовой архитектуры выглядит следующим образом.

Общая архитектура проста, и почти все базы данных обеспечивают функцию первичной и вторичной репликации, такие как Mysql, Oracle, MongoDB и т.д. В этой архитектуре резервная база данных в основном отвечает за резервное копирование данных и не участвует в реальных бизнес-операциях чтения и записи.Если резервная машина заменяется хостом, требуется ручное управление.

2. Анализ преимуществ и недостатков

• Клиенту не нужно знать о существовании резервной машины.Даже после аварийного восстановления первоначальная резервная машина вручную заменяется главной.Клиенту нужно только просто изменить адрес подключения, и архитектуру приложения менять не нужно.
• Хосту и резервному серверу нужно только выполнять репликацию данных, и им не нужно выполнять сложные операции, такие как оценка состояния и переключение между активным и резервным сервером.

Недостатки этой архитектуры также более очевидны:

• Резервная машина в основном используется для резервного копирования данных.Если архитектура приложения не предусматривает разделения чтения и записи, это приведет к потере затрат.
• После сбоя требуется ручное вмешательство, и автоматическое восстановление не может быть выполнено, однако эффективность ручной обработки относительно низка, и процесс восстановления также подвержен ошибкам.

архитектура «ведущий-ведомый»

Между архитектурой ведущий-подчиненный и архитектурой ведущий-подчиненный разница всего в одном слове, но разница между фактической архитектурой приложения очень велика. В архитектуре «главный-подчиненный» резервная база данных не участвует в бизнес-операциях, в то время как в архитектуре «главный-подчиненный» подчиненная база данных должна участвовать в бизнес-операциях. записываются в основную базу данных, а операции чтения считываются из подчиненной базы данных.

1. Схема топологии базовой архитектуры master-slave выглядит следующим образом.

2. Анализ преимуществ и недостатков Эта архитектура очень удобна для небольших операций записи и больших операций чтения. Операции чтения могут быть распределены между несколькими резервными базами данных, чтобы уменьшить нагрузку на главную базу данных, пока подчиненная база данных не возложит слишком большую нагрузку на главную базу данных, или полоса пропускания между главной и подчиненной не станет узким местом.

По сравнению с активно-резервной архитектурой она имеет следующие преимущества:

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

недостаток:

• В архитектуре ведущий-ведомый ведомая библиотека должна предоставлять услуги чтения.Если задержка репликации ведущий-ведомый велика, данные будут несогласованными;
• Архитектура приложения должна быть изменена.Как правило, добавляется разделение чтения-записи, а сложность выше, чем у активного и резервного;
• После сбоя требуется ручное вмешательство, и автоматическое восстановление не может быть выполнено, однако эффективность ручной обработки относительно низка, и процесс восстановления также подвержен ошибкам.

главный-ведомый переключатель

У обеих вышеупомянутых архитектур есть две общие проблемы:

• После сбоя основной библиотеки операция записи не может быть выполнена
• При возникновении проблемы в основной библиотеке требуется ручное вмешательство для переключения с одной библиотеки на основную, а ручное переключение может быть задержано или выполнено аварийное отключение.

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

преимущество:

• Это решает проблему ручного вмешательства, значительно сокращает время простоя и в определенной степени защищает безопасность жизни эксплуатационного и обслуживающего персонала.
  недостаток:
• Архитектура сложная, и после внедрения стороннего посредника необходимо обеспечить высокую доступность стороннего посредника.

Рекомендуется узнать о mysqlMHAархитектуру или используйте ZK и Keepalived, чтобы самостоятельно построить архитектуру переключения master-slave.

основная основная конструкция

Архитектура мастер-мастер также называется репликацией мастер-мастер.Обе базы данных являются мастер-базами данных, копируя данные друг в друга, и клиент может выбрать любую базу данных для операций чтения и записи.

По сравнению с переключением ведущий-ведомый архитектура ведущий-ведущий имеет следующие преимущества:

• Обе базы данных являются основной базой данных, и нет понятия переключения между ними.
• Клиенту не нужно различать хосты с разными ролями, и он может отправлять операции чтения и записи в любую базу данных.
• Простая архитектура

Но разрешать запись в обе первичные базы данных опасно:

• Две базы данных A и B используют самовозрастающие первичные ключи. Идентификатор равен 1 после того, как пользователь вставлен в базу данных A, и идентификатор равен 1 после того, как пользователь вставлен в базу данных B. Конфликты данных
• При этом будет большая проблема с обновлением данных БД, добавлением таблицы библиотеки АБtbЕсть 1 поле Col, значение 1. Такие как библиотекаupdate tb set col = col +1, библиотека B для выполненияupdate tb set col = col * 2, После окончательного выполнения значение одних данных становится равным 4, а значение другой базы данных становится равным 3, и ошибки репликации нет.В случае возникновения проблемы ее локализация займет много времени.
  Таким образом, архитектура main-main должна гарантировать, что данные могут быть реплицированы в обоих направлениях, и существуют строгие требования к дизайну данных.Как правило, она подходит для этих сценариев с временными, потерянными и перезаписанными данными.

Для получения дополнительной информации, пожалуйста, обратите внимание на публичный номер: JAVA Daily Record