Приветствую всех вОблако Tencent + сообщество, получить больше крупной технической практики Tencent по галантерее~
Эта статья написанаОблачная база данных Tencent TencentDBОпубликован вКолонка «Облако + сообщество»
Ван Цзякунь, старший инженер Tencent, облачная реляционная модель TencentDatabasemysql.Ответственное лицо имеет многолетний опыт исследований и разработки клиентов и баз данных. На клиенте IOS,MySQL,PostgreSQL,SQL ServerИ другие продукты имеют богатый опыт в области исследований и разработок и планирования продукта.
Давайте начнем наш основной контент сегодня.Сегодня мы в основном используем что, почему и как это сделать.Эта идея показывает вам высокую доступность MySQL.
Сначала позвольте мне представитьЧто такое высокая доступность?在我看来就是业务在高质量的情况下，对用户提供服务的可运行的总时长。其实我们从事MySQL相关的工作，大家对9这个数字比较敏感，大家选择云厂商云产品的时候，首先会看它的数据库有几个9。目前腾讯云MySQL可以做到99.95，全年在25分钟的样子。
Насколько я знаю, наивысшая высокая доступность может достигать 3 девяток, 1 6, достичь 4 9 с очень сложно, и это предел достижения 5 9 с.
Зачем нужна высокая доступность? Поскольку существует слишком много неконтролируемых факторов, например, землеройных машин, я помню, что такие инциденты происходят практически раз в два года.Я до сих пор помню, что некая магистральная сеть в Сяошань, Ханчжоу, была разрушена в 2015 году. некоторые услуги Али будут недоступны. Кроме того, бывают какие-то подобные перебои с электричеством, какие-то стихийные бедствия и так далее. Стоит отметить, что в некоторых случаях ошибок операций со стороны обслуживающего и обслуживающего персонала, rm весь каталог или отбрасываемая таблица, есть народная поговорка, что это от удаления базы данных до побега. Есть много неконтролируемых факторов. Ваши данные и пользователи — ваши. Если они неконтролируемые, ваш бизнес потерпит неудачу.
Вообще говоря, есть два показателя, которые будут использоваться в качестве эталонов измерения: первый — RPO, а второй — RTO. RPO — это объем данных, потерянных с момента начала сбоя до восстановления службы, а RTO — это время, прошедшее от начала сбоя до восстановления службы.
как мы это делаем? В целом в отрасли существует три способа: левый основан на автономном хранилище, таким образом, в игре больше сцен, верхний - это отдельные компьютерные узлы, а нижние - три копии для обеспечения надежности данных. После отказа вычислительного узла быстро перейти на другой вычислительный узел, конечно, мы Tencent облако MySQL запустили эту модель, относительно очень дешево, это базовая версия, на официальном сайте вы можете приобрести эту модель. Второй основан на общем хранилище, также называемом режимом общего диска, который более типичен для архитектуры Oracle RAC. Основываясь на базовом общем режиме хранения, множестве вычислительных узлов, использующих верхний уровень, сбои вычислительного узла могут быть сделаны немедленно ip из списка, не влияя на доступ пользователя. Третий основан на режиме репликации данных, не будет делиться ни с чем, режим передачи данных, соглашение о репликации данных, достигнутое на двух хостах, согласованность находится в центре внимания этого объяснения. В дополнение к высокодоступному узлу хранения, весь канал должен быть высокодоступным, например, наша комната IDC, коммутаторы, серверы и хосты.
Здесь мы представляем высокодоступную инфраструктуру. Сначала мы часто слышим несколько терминов,Двойная жизнь в городе, второйТри центра в двух местах, Три центра в двух местах — это сильный спрос на финансовые сценарии, по сути, грубо говоря, у нас есть два дата-центра в одном городе в 10 километрах от двух узлов, и еще один центр аварийного восстановления в 100 километрах. Высокая доступность компьютерного зала. Кроме того, в него входят сеть и хост.На самом деле структура такая.По крайней мере, у вашей сети коммутаторов есть резервные копии.После выхода из строя одного требуется замена другого.
Давайте сосредоточимся на высокой доступности репликации данных, сначала представим резервное копирование, резервное копирование действительно очень важно, а резервное копирование является последней гарантией того, что его невозможно сделать, поэтому я предлагаю всем, будь то бизнес, используемый в облаке, Или сделайте резервную копию своего собственного IDC, насколько это возможно.
Резервное копирование MySQL в основном состоит из обоих: логического резервного копирования, физического резервного копирования. Логические резервные копии обычно используют официальный MySQLDUMP и сторонние инструменты MYDUMPER. Преимущество MyDumper заключается в многопоточном резервном копировании и высокой скорости. Физические резервные копии используют Percona XTRABACKUP, который может быть неприменим из-за потоковых вычислений и сжатия, резервного копирования с высокой скоростью, низкой скоростью и небольшим объемом памяти. Последнее — это моментальный снимок, и наша базовая версия резервной копии Tencent создается с помощью моментальных снимков.
На основании способа репликации данных, как правило, два узла являются мастером и рабом. Как обеспечить консистенцию данных? Фактически, передача данных осуществляется через протокол репликации, и переключатель переключается, чтобы убедиться, что служба может быть восстановлена как можно скорее после неудачи. Диаграмма справа в основном такая же, как Tencent Cloud MySQL. Мы принимаем мастер-рабский подход. Рабочий узел отвечает только за переключение. Когда главный узел зависает, автоматическое обнаружение неисправности и автоматический перевод используются для восстановления бизнеса как как можно скорее., Кроме того, для разделения чтения-записи, Tencent Cloud MySQL теперь может поддерживать пять узлов только для чтения на одном мастере.
Давайте введем репликацию.Прежде чем вводить репликацию, необходимо ввести важное понятие: binlog, binlog — это бинарный файл, в котором в основном записывается информация SQL, которую пользователи обновляют в базу данных.Как выглядит binlog? На диске это выглядит так.После использования событий show binlog он будет записывать некоторую метаинформацию, такую как местоположения, события и т.д. оператор внутри Он закодирован с использованием base64, и после декодирования он выглядит так: вы можете видеть, что это оператор вставки. Когда вы пишете бинлог? Глядя на эту картинку, мы знаем, что есть два этапа отправки транзакции: подготовка и фиксация, на каком этапе записывается бинлог? На самом деле бинлог записывается после подготовки и перед фиксацией, в то время как редолог и ундолог будут генерироваться в процессе записи транзакции, в чем разница между ними? Мы знаем, что MySQL — это реляционная база данных с несколькими движками, binlog — это журнал уровня сервера MySQL, а redolog — это журнал уровня InnoDB движка MySQL; другое отличие состоит в том, что время записи двух различно, redolog записывается каждый раз, когда оператор SQL выполняется на этапе подготовки. Выполняется повтор, а binlog записывается до того, как подготовка завершает фиксацию. Как MySQL обеспечивает согласованность данных в архитектуре master-slave? Как мы все знаем, чтобы обеспечить производительность MySQL, данные сначала записываются в память, а затем помещаются на диск. При работе вашей БД происходит простои, а при повторном восстановлении машины часть данных может быть размещена на диске, а часть данных на диске не разместилась. В это время mysql находит последний сайт синхронизации или GTID binlog, чтобы определить, какие экземпляры в redolog или undolog нужно откатить и какие транзакции нужно переделать. Кроме того, при записи журналов, таких как redolog или binlog, для обеспечения высокой производительности MySQL также сначала записывает память, а затем размещает ее на диске, поэтому стратегия ведения журнала также будет влиять на согласованность данных. . Чтобы обеспечить согласованность данных, рекомендуется настроить параметры, участвующие в журнале, на «двойную 1», как показано на рисунке.
Давайте посмотрим на весь процесс копирования, который на самом деле очень прост: Мастер сбрасывает бинлог на диск через поток дампа, на Слейве будет два потока, а именно поток ввода-вывода и поток SQL. Поток ввода-вывода принимает двоичный журнал от Мастера и приземляется для формирования журнала реле.Поток SQL параллельно считывает информацию SQL в журнале реле и выполняет действие воспроизведения. Вообще говоря, существует три типа репликации: асинхронная репликация, полусинхронная репликация и строгая синхронизация. Разница между ними заключается в том, что результат выполнения SQL возвращается клиенту. Асинхронная репликация, Мастер не заботится о Слейве, а Мастер возвращается к клиенту сразу после выполнения sql.Этот метод имеет наилучшую производительность, но есть вероятность несогласованности данных, для сильной синхронизации Мастер полностью заботится о Ведомый, и ждет, пока ведомый воспроизведет журнал реле, прежде чем вернуться к клиенту.Для клиента этот метод может обеспечить надежную согласованность данных, но его производительность имеет определенные потери; полусинхронизация означает, что главная часть заботится о ведомом, думая, что пока бинлог передается на слейв и попадает в релейлог, его можно вернуть клиенту. Полусинхронизация является сбалансированной реализацией: с одной стороны, она обеспечивает согласованность данных, а с другой — учитывает производительность базы данных.
Во время процесса репликации мы часто сталкиваемся с проблемами задержки.Как показано на рисунке, репликация проходит через три этапа: дамп бинлога отбрасывания потока, релейный журнал отбрасывания потока ввода-вывода и воспроизведение потока SQL.Какой из трех шагов является узким местом? Это поток SQL, потому что поток SQL выполняет SQL последовательно во время процесса воспроизведения журнала, а Мастер параллельно предоставляет услуги внешнему миру. Таким образом, узким местом здесь является поток SQL. Вы можете решить проблему задержки, включив параллельную репликацию: MySQL 5.6 основана на параллельной репликации на уровне базы данных, MySQL 5.7 основана на параллельной репликации с логическими часами, то есть параллелизме на уровне таблиц, а MySQL 8.0 — на параллельной репликации на уровне строк с более мелкая гранулярность, эффективность репликации выше.
Я просто сказал репликация на уровне протокола.На самом деле есть еще один способ репликации данных на блочном уровне,которому все равно какой верхний уровень,а нужно только обеспечить репликацию данных на уровне диска. Конечно, этот метод используется реже. После разговора о репликации, давайте поговорим о переключении.На самом деле MySQL официально не предоставляла возможности автоматического обнаружения и передачи ошибок раньше, и в основном полагается на сторонние инструменты для ее достижения.
Первый Keepalived, Master и Slave обнаруживают друг друга и постоянно запрашивают друг у друга статус выживания. Когда есть сетевое дрожание или проблемы с сетью, может возникнуть проблема с разделенным мозгом, становится два мастера, и данные записываются в беспорядке. Второй — метод MMM, M1M2 — это главный и резервный узел друг друга, плюс узел Slave для резервирования. Судя по рисунку, несмотря на то, что это двойной мастер, в этом режиме только один узел может записывать в один и тот же момент времени.Когда главный узел записи окажется неисправным, VIP будет переключен на другой мастер. В целом, этот метод относительно старый и имеет много проблем. Третий тип широко используется MHA.Этот метод состоит из групп репликации и узлов управления.Каждая группа репликации состоит как минимум из трех узлов данных.Агент мониторинга развертывается на узлах данных и регулярно сообщается узлу управления , Когда возникает проблема с узлом, управляющий узел решает, переключаться ли на подчиненный узел. Tencent Cloud самостоятельно реализовала набор обнаружения неисправностей Структура показана на рисунке справа Узел монитора с гарантированной высокой доступностью выполняет обнаружение неисправностей и переключение. Кроме того, мы все еще занимаемся реконструкцией высокой доступности MySQL, к тому времени мы можем добиться обнаружения сбоев и восстановления в течение 30 секунд, что значительно повышает высокую доступность.
Давайте высокую доступность архитектуру кластера, более известным является PXC, MGC, монсеньор, PXC и MGC похожи, монсеньор является официально при условии, высокой доступна архитектурой с неудачной передачей. Общая иерархия, как это, и монсеньор в виде плагина. Монсеньор главным образом для преобразования протокола репликации, поскольку MGR поддерживает много, так что еще один фокус обнаружение конфликтов. Если несколько узлов одновременно записывается с первичный ключ, в соответствии с которым дело? MGR является обнаружение конфликта на основе протокола Paxos. Ниже мы одобрительно структуру, и монсеньор поддерживает несколько узлов, написанных, то есть, игра автоматически отклоняется, и кластер автоматически присоединился после восстановления. Эта картина ввести логику потока MGR данных, а также три узла на карте составляет кластер минимума MGR. Предположим, что DB1 имеет представление записи, в фазе подготовки, плагин MGR генерирует коллекцию WriteSet и трансляции его к другим узлам. Этот набор содержит WriteSet этого представленные Двоичный и уникальный ключ, который состоит из имени БД, имени таблицы и первичного ключа. Здесь вы можете увидеть, что MGR имеет ограничение, вы должны иметь первичный ключ в таблице, и вы не должны быть в противоречии. Давайте поговорим об этом, когда узел получает эту информацию, она будет сравнивать, каждый узел имеет кэш, сохраняет текущую синхронизацию, единственный ключ, соответствующий GTID SET. По выравнивания, возвращает результаты DB1, до тех пор, как более половины узла возвращает OK, вы можете представить, то DB1 выполнит Двоичный обосновалась операцию диска, а затем вернуться к клиенту. Другие узлы выполняют действия, записанные в RELAYLOG, с последующим воспроизведением. Если узел большинства возвращает конфликт, DB1 выполняет ROLLBACK операции, и другие узлы упадут Двоичную, что DROP будут скопированы.
На самом деле идеи PXC и MGC похожи, и следует сказать, что MGR учится у них, потому что PXC и MGC вышли относительно рано, и здесь они похожи Мастер-нода транслирует набор записи WriteSet, а после трансляции , осуществляется проверка и вынесение решения.
Напоследок поговорим об архитектуре высокой доступности NewSQL, в первую очередь отдадим должное AWS, которая вырастила очень хороший продукт NewSQL — Aurora. Так как же появилась Аврора? Это связано со схемой базы данных AWS. Давайте посмотрим на эту картинку. База данных AWS структурирована на виртуальных машинах и облачных дисках. Все мы знаем, что MySQL имеет много журналов, поэтому многие операции ввода-вывода выполняются через сеть с большими затратами времени. Поэтому архитектура сети AWS IO является его узким местом, и производительность не может увеличиться. Исходя из этого, давайте познакомимся с Авророй.
Aurora — это архитектура, которая разделяет вычисления и хранилище, что является типичной структурой совместно используемого диска. Базовое хранилище использует 6 копий, которые развернуты в трех разных зонах доступности, что может гарантировать, что одна зона доступности выйдет из строя или что данные не будут потеряны в случае потери одной копии не более двух зон доступности, а бизнес может нормально обслуживаться извне. Концепция Aurora заключается в том, что «журналы — это базы данных», она полностью изменила уровень хранения MySQL, отказалась от многих журналов и оставила только Redolog с возможностью преобразования redolog в страницу Innodb. Таким образом, Aurora утверждает, что снижает коэффициент ввода-вывода как минимум на 85%. Кроме того, он передает резервное копирование и откат на узлы хранения, что делает восстановление из резервной копии более быстрым и гарантированным. В целом Aurora кажется относительно приземленной, а стоимость относительно низкой.
Другой-Полярный Alibaba Cloud.Концепция отличается от AWS.Alibaba Cloud считает, что будущая сеть не является проблемой, и будущая сеть может быть близка к качеству шины.Поэтому она встроена в сетевой компьютер RDMA. комната, и в журнале есть несколько основных действий, что обеспечивает последующее сообщество MySQL Новые функции могут быть быстро повторены в последнее время. Polardb также представляет собой архитектуру с общим диском, и его узлы хранения используют протокол ParallelRaft для обеспечения целостности данных. Видно, что это тоже отличная архитектура, но стоимость относительно высока.
Мы, собственный NewSQL от Tencent Cloud, находимся в стадии исследований и разработок, но он еще не был официально запущен.Наше имя CynosDB.Для сравнения, наша философия заключается в том, чтобы учитывать и то, и другое.В будущем, в соответствии с базовой реализацией новых высоко- сетевому оборудованию, большую роль будет играть производительность, более надежное обслуживание и более высокая доступность. Пожалуйста, подождите и посмотрите.
Вот и все, чем я делюсь на этот раз.Чтобы узнать о других передовых технологиях баз данных, вы можете подписаться на нашу официальную учетную запись: Tencent Cloud Database CDB.
Q & A
В: Я хотел бы спросить, какую архитектуру мы в основном используем в индустрии игр Tencent с высокой степенью параллелизма?
О: В Tencent много проектов собственной разработки, но в основном мы основаны на репликации данных. Внутри есть распределенные кластерные архитектуры, такие как phxsql.
В: Как обеспечить фиксированную задержку общей базы данных в случае высокого параллелизма?
О: Можно включить параллельную репликацию, а бизнес можно разделить на подбазы данных и подтаблицы и распределить по нескольким экземплярам.
В: Например, в играх в пиковый период игры одновременно будет много людей онлайн, как в этом случае просматривать данные в фоновом режиме?
О: Горячие данные могут быть многоуровневыми.Первый слой может кэшироваться KV, например Redis, для улучшения чтения горячих данных.Последний слой использует MySQL для периодической синхронизации данных на диск.
В: Как в этом случае убедиться, что база данных непротиворечива?
О: Вы можете записывать данные напрямую в базу данных MySQL, минуя KV-кэш, при чтении данных в кеше нет, и их нужно извлекать из БД. Кроме того, кэш KV также имеет возможность выгрузки, а некритические данные также могут выгружаться без использования MySQL.
Связанное Чтение [Ежедневная рекомендация курса] Машинное обучение в действии! Быстрый старт бизнеса в сфере онлайн-рекламы и знание CTR
Эта статья была разрешена автором для публикации в сообществе Tencent Cloud + Для получения дополнительных оригинальных текстов, пожалуйстанажмите
Найдите и подпишитесь на общедоступную учетную запись «Сообщество Yunjia», получите технические галантереи как можно скорее и ответьте на 1024 после подписки, чтобы отправить вам подарочный пакет технических курсов!
Огромный технический практический опыт, все вСообщество Юнцзя!