краткое содержание

В этой статье рассказывается о первой большой ошибке базы данных MySQL, связанной с задержкой репликации локализованной среды ARM. Автор впервые проанализировал причины этого явления, включая бинлог основной библиотеки. поток дампа, поток ввода-вывода ведомой библиотеки, SQL-поток и Координационная ведомой библиотеки нить и другие факторы в различных аспектах. Затем,Автор провел детальную отладку и анализ,Обнаружена ошибка совместимости в функции получения размера строки кэша ЦП общественной версии MySQL под архитектурой ARM. наконец,Автор предложил решение и использовал TXSQL в отечественной архитектуре ARM, чтобы избежать этой проблемы.

Вытаптывание фона

На фоне информационных инноваций и волны локализации регулирующие органы выдвинули более высокие требования к безопасности и надежности финансовых баз данных. Чтобы соответствовать нормативным требованиям, мы попытались развернуть базу данных MySQL на внутренних серверах ARM в нескольких сценариях платежного бизнеса.

Когда бизнес был впервые запущен,База данных работает относительно гладко. через некоторое время,Мы наступили на этоПервый большой подводный камень БД под отечественную архитектуру。

Я обнаружил, что в периоды пиковой нагрузки подчиненная база данных MySQL испытывает большие задержки репликации. Триггерный сценарий: Около 18:00 в пиковый период работы скорость вставки достигла 1,7 тыс./с, а скорость обновления — 1,7 тыс./с. ,Прямо сейчасTPS достигает 3,4 к/спосле,Копирование ведомой библиотеки архитектуры ARM будет происходить с задержкой, тогда как копирование ведомой библиотеки архитектуры X86 происходит нормально.

Начните с принципов

Проблема задержки репликации подчиненной базы данных MySQL на самом деле является распространенной проблемой в области баз данных. Чтобы проанализировать проблему задержки репликации, мы сначала рассмотрим основные принципы репликации «главный-подчиненный».

• Поток дампа binlog основной библиотеки отвечает за отправку binlog во ведомую библиотеку.

Когда подчиненный узел подключается к главному узлу, главный узел создает поток дампа бинлога для отправки событий бинлога.

• Поток ввода-вывода ведомой библиотеки отвечает за получение бинлога и запись журнала реле.

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

• SQL-поток из библиотеки отвечает за чтение реле войти и воспроизвести транзакцию

SQL-поток отвечает за чтение relay log События в SQL анализируются в конкретный SQL и выполняются, что в конечном итоге обеспечивает согласованность данных «главный-подчиненный».

• В режиме параллельного копирования из библиотеки также есть поток Координатора, отвечающий за чтение реле. журнал распределен в SQL-поток

В режиме параллельной репликации существует отдельный Coordinator Поток конкретно отвечает за чтение реле logбревно,и распределить транзакции чтения на несколькоSQL-потоксправиться。

В соответствии с основными принципами репликации «главный-подчиненный», изложенными выше, задержки репликации могут возникать в нескольких потоках:

1. Поток дампа binlog основной библиотеки медленно отправляет события binlog;
2. Получение событий binlog из потока ввода-вывода библиотеки и запись их в журнал реле происходит медленно;
3. Чтение журнала ретрансляции из библиотеки Координационная нить и передача его в SQL-поток происходит медленно;
4. Выполнение транзакций из библиотеки SQL-поток происходит медленно.

Обычно,Чтение и запись журналов — это последовательное чтение и запись.,Быстрее наиболее вероятной причиной задержки копирования является медленный SQL-поток;,Различные ситуации, такие как низкая производительность базы данных и слишком большие транзакции, могут привести к тому, что SQL-поток будет медленно воспроизводить транзакции.,Это, в свою очередь, приводит к задержкам в копировании.

Выхода нет, несмотря на горы и реки

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

SQL-поток

SQL-поток Эффективность транзакций воспроизведения во многом зависит от Большой бизнес、Производительность ввода-вывода подчиненной библиотеки、Параллелизмсвязано с другими факторами。

• Большой бизнес

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

• Производительность ввода-вывода подчиненной библиотеки

С точки зрения мониторинга производительности ввода-вывода ARM-серверов,Использование операций ввода-вывода одного диска очень велико и достигает 100 %.,Но подождии Очевидных отклонений в параметрах очереди нет.；кроме тогоMySQLПисатьбревнонитьCPUСкорость использования также очень высока。Задержка репликации может быть связана с производительностью ввода-вывода ведомой библиотеки.

затем,Я попытался записать два диска NVMe в LVM.,Улучшение возможностей ввода-вывода в секунду,Затем перенесите данные в LVM.,Результат: Скорость воспроизведения SQL-поток существенно не изменилась.

затем,Пробую отключить запись логов из настроек библиотеки double 1,Уменьшить зависимость воспроизведения от возможностей ввода-вывода,Результат: Скорость воспроизведения SQL-поток также существенно не изменилась.

Вывод: задержка репликации не имеет ничего общего с производительностью ввода-вывода подчиненной библиотеки.

• Параллелизм

SQL-поток Параллелизма недостаточно, что приводит к задержкам при копировании?

В этом легко убедиться. Я последовательно настроил параллельные потоки на 6, 8, 16 и 24. Результат: скорость воспроизведения из библиотеки практически не изменилась и осталась на уровне 1,68 К/с.

• связанное ядро

Из-за архитектуры ARM Улучшение производительности источников очень очевидно. Я попробовал привязать SQL-поток к указанному процессору, а также привязал память подчиненной библиотеки. Результат: скорость воспроизведения SQL-поток увеличилась всего на 6%; , связанное ядро ​​имеет определенное улучшение показателей,Но дело не в задержке копирования.

На основании вышеизложенного анализа и проверки влияние SQL-поток в принципе можно исключить.

Координационная нить

Единственное, что может быть затронуто, это Координационная нить.

Я пересмотрел отложенную сцену копировать,Нашел несколько подсказок. Подчиненная библиотека архитектуры ARM копировать задержку,Похоже, что параллелизм воспроизведения SQL невысок. Хотя в слейв-библиотеке 8 параллельных номеров SQL-поток,Но в нем всего 1-2 активных потока,Остальные темы простаивают,И интервал идентификаторов транзакций между SQL-потками очень велик,Статус следующий:

В качестве сравнения,Параллелизм воспроизведения полусинхронной подчиненной библиотеки под архитектурой X86 существенно выше, чем у узла ARM.

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

Так что же именно приводит к снижению параллелизма воспроизведения SQL?

Это естественно предполагать,Нагрузка Координационной выше?,Приводит к снижению эффективности распределения транзакций.,Это оставляет SQL-поток в основном бездействующим.

Мониторинг ЦП в периоды пиковой нагрузки можно увидеть,Загрузка ЦП координатора Координационная нить на подчиненном узле архитектуры ARM составляет 99,9%.,Весь логический процессор был израсходован. Загрузка процессора SQL-поток обычно составляет всего 40%.

В качестве сравнения,X86Архитектура подчиненного узла Координационная Загрузка ЦП нити составляет менее 40%, а загрузка ЦП SQL-поток составляет 30-50%.

Может ли быть так, что вычислительная мощность одноядерного процессора в архитектуре ARM ниже, чем в архитектуре X86?,Причины высокой загрузки ЦП,В результате транзакции не могут эффективно распределяться по SQL-потокам.,Воспроизведение из библиотеки заблокировано?

Что касается вопроса вычислительной мощности ЦП, я консультировался со студентами, связанными с сервером TEG, и получил следующий отзыв: «ЦП X86 — это 4208, с 8 ядрами и 16 потоками. При низкой нагрузке одно ядро ​​может увеличить частоту до 3,2». G, а вычислительная мощность эквивалентна одному физическому ядру; Kunpeng имеет только физическое ядро, а частота одного ядра составляет до 2,6G, поэтому частота ядра Kunpeng находится в невыгодном положении при низкой нагрузке. Преимущество Kunpeng в том, что он имеет больше ядер и лучшие возможности параллельного выполнения».

Кажется,ARMОдноядерная производительность физического ядра данной архитектуры действительно лучше, чемX86Архитектура хуже。Предварительные выводы можно сделать здесь：Возможности одноядерной обработки ARM недостаточны (или по другим основным причинам),Это приводит к низкой эффективности обработки SQL. Координационная нить.,Параллелизм воспроизведения SQL невысокий,Вызывает задержку копирования библиотеки при высоком уровне параллелизма на архитектуре ARM.

Однако Координационная нить из библиотеки может использовать только одно логическое ядро, поэтому эта проблема неразрешима! ! ! Может ли быть так, что предел производительности воспроизведения ведомой библиотеки MySQL в архитектуре ARM составляет 3,4 КБ/с?

Еще одна деревня со скрытыми цветами и яркими ивами.

Проблему еще предстоит решить, ведь локализация баз данных — это общая тенденция.

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

Тонкий анализ

первый,Используйте график пламени для анализа времени системного вызова MySQL. Ниже приведен системный вызов Координационная нитьCPU MySQL в архитектуре ARM.,Функция get_slave_worker вызывает,На функцию get_least_occupied_worker приходится очень большая доля.

Сравнивая график пламени ведомой библиотеки ARM и ведомой библиотеки X86, разница в том, что Координационная нить вызывает здесь функцию get_slave_worker.

Как видно из двух приведенных выше рисунков, время процессора MySQL, вызывающего функцию get_least_occupied_worker в архитектуре ARM, намного превышает время MySQL в архитектуре X86, а функция get_free_woker почти никогда не вызывается. Кроме того, большая часть использования ЦП в функции get_least_occupied_worker приходится на __sched_yield.

При этом в сочетании с pstack печатается Координационная Информацию о стеке нить, вы можете увидеть Координационная нить получает самый простой SQL-поток через функцию get_least_occupied_worker(), а затем регистрирует новую транзакцию с помощью Commit_order_manager, вставляя элемент в незаблокированную очередь Commit_order_queue. Системный вызов sched_yield() вызывается при постановке в очередь.

Thread 16 (Thread 0xfffb8fe3efe0 (LWP 127910)):
#0  0x0000fffbcb716918 in sched_yield () from /lib64/libc.so.6
#1  0x00000000019bc8a0 in __gthread_yield () at /usr/include/c++/7/aarch64-redhat-linux/bits/gthr-default.h:692
#2  yield () at /usr/include/c++/7/thread:351
#3  push (to_push=2, this=0xfff330f002e0) at mysql-arm.7.5/sql/containers/integrals_lockfree_queue.h:833
#4  operator<< (to_push=<synthetic pointer>, this=0xfff330f002e0) at mysql-arm.7.5/sql/containers/integrals_lockfree_queue.h:750
#5  cs::apply::Commit_order_queue::push (this=0xfff330f00290, index=2) at mysql-arm.7.5/sql/changestreams/apply/commit_order_queue.cc:172
#6  0x00000000019b419c in Commit_order_manager::register_trx (this=<optimized out>, worker=worker@entry=0xfff33091d000) at mysql-arm.7.5/sql/rpl_replica_commit_order_manager.cc:67
#7  0x00000000019d6a34 in Mts_submode_logical_clock::get_least_occupied_worker (this=0xfff330f900b0, rli=0xfffbca5eb000, ws=<optimized out>, ev=0xfff32afc1e60) at mysql-arm.7.5/sql/rpl_mta_submode.cc:976
#8  0x0000000001916c30 in Log_event::get_slave_worker (this=this@entry=0xfff32afc1e60, rli=rli@entry=0xfffbca5eb000) at mysql-arm.7.5/sql/log_event.cc:2770
#9  0x0000000001917c34 in Log_event::apply_event (this=this@entry=0xfff32afc1e60, rli=rli@entry=0xfffbca5eb000) at mysql-arm.7.5/sql/log_event.cc:3307
#10 0x00000000019990f4 in apply_event_and_update_pos (ptr_ev=0xfffb8fe3d968, ptr_ev@entry=0xfffb8fe3d9b8, thd=thd@entry=0xfff330e53000, rli=rli@entry=0xfffbca5eb000) at mysql-arm.7.5/sql/rpl_replica.cc:4391
#11 0x00000000019a9290 in exec_relay_log_event (thd=0xfff330e53000, rli=rli@entry=0xfffbca5eb000, applier_reader=0xfffb8fe3e3f0, applier_reader@entry=0x0, in=in@entry=0xfff32afc1e60) at mysql-arm.7.5/sql/rpl_replica.cc:4908
#12 0x00000000019aba84 in handle_slave_sql (arg=arg@entry=0xfffbca5dc000) at mysql-arm.7.5/sql/rpl_replica.cc:7083
#13 0x000000000212ab60 in pfs_spawn_thread (arg=0xfff3373d0260) at mysql-arm.7.5/storage/perfschema/pfs.cc:2947
#14 0x0000fffbcbe87c48 in start_thread () from /lib64/libpthread.so.0
#15 0x0000fffbcb72f600 in thread_start () from /lib64/libc.so.6

Координационная расположена ранее по схеме пламени нить Коэффициент использования одноядерного процессора достигает 99,9%, что в принципе можно подтвердить Координационная нить тратит большую часть своего времени на выполнение системного вызова sched_yield(). Функция системного вызова sched_yield() обычно используется для спин-блокировок в пользовательском режиме.,Используется для освобождения процесса When от ЦП.,Чтобы другие процессы могли получить больше фрагментов процессорного времени. Конкуренция за блокировку процессора должна достичь 100 %.,sched_yield — это всего лишь результат конкуренции спин-блокировок. То есть,99,9% загрузки ЦП Координационной нитью является результатом спин-блокировок.,Не причина.

В сочетании с приведенной выше информацией о стеке,Видно, что Координационная под архитектурой ARM Нить - при вставке новой транзакции в lock-free очередь Commit_order_queue условия не выполняются и ЦП добровольно переносится. Commit_order_queue должен обеспечивать порядок отправки подчиненных транзакций и быть главным в сценариях многопоточного воспроизведения. библиотека согласована и создала очередь заказов на фиксацию транзакций в параметрахslave_preserve_commit_order=1 вступает в силу.Этот параметр в основном предназначен для обеспечения единообразия порядка отправки транзакций «главный-подчиненный».,После включения он оказывает большое влияние на скорость параллельного воспроизведения ведомой библиотеки.,Это справедливо как для архитектуры X86, так и для ARM. Этот параметр необходимо включить в финансовой базе данных.,В MySQL В версии 8.0 он также включен по умолчанию. Тогда очень вероятно, что он зафиксируется В режиме заказа код MySQL несовместим с архитектурой ARM.

Проверьте внимательно

первый,существоватьARMАрхитектурная рабская библиотекасерединапопробуй закрытьslave_preserve_commit_orderпараметр,Скорость воспроизведения из библиотеки мгновенно увеличивается в несколько раз (ожидаемый результат). в то же время,Отключите этот параметр и для подчиненной библиотеки архитектуры X86.,Результат сравнения: скорость воспроизведения ведомой библиотеки ARM и ведомой библиотеки X86 практически одинакова.,соответствует предположениям.

Далее мы сравнили MySQL на базе архитектуры ARM. 5.7 и 8.0.28и последний8.0.34Версия,существовать Открытьslave_preserve_commit_orderпараметрчас,Скорость воспроизведения из библиотеки не может превышать примерно 3,4К/с.,Это показывает, что эта проблема широко распространена в сообществе MySQL.

Затем сравнение подтвердило, что скорость воспроизведения TXSQL-8.0.30 из библиотеки в этом сценарии под архитектурой ARM может быть значительно выше, чем 3,4 К/с, что по сути соответствует версии X86. Возможно, TXSQL обнаружил и исправил эту ошибку в версии сообщества.

Итак, я быстро проконсультировался со своими однокурсниками по ядру TXSQL, и получил отзыв, что они не оптимизировали проблему задержки копирования в архитектуре ARM. Линия TXSQL не достигла прорыва.

Тогда вам останется только зайти в официальное сообщество, чтобы узнать, есть ли какие-либо связанные с этим ошибки. Я поискал в сообществе все вопросы, связанные с копированием под архитектуру ARM, но соответствующих ошибок не нашел.

Это немного невероятно.

Очевидно, это должна быть ошибка совместимости MySQL с архитектурой ARM, но я не могу найти соответствующий список ошибок. Кажется, TXSQL явно решил эту ошибку, но одноклассники по ядру не признались, что они провели оптимизацию в этой области. В то время это казалось немного трудным для понимания.

повороты и повороты

Одну волну за другой мы сталкивались с еще одной проблемой прерывания репликации подчиненных устройств в архитектуре ARM. Похоже, это также связано с совместимостью архитектур MySQL и ARMJ.

При отправке ОШИБКИ в официальное сообщество,Кстати, я рассказал сообществу оARMархитектурныйBUGПеревернул его снова。На этот раз я наконец нашел соответствующую статьюBUG：Parallel replication not working with slave_preserve_commit_order=1 . (Похоже, что возможность поиска ошибок сообщества все еще нуждается в улучшении~)

Согласно описанию ошибки, MySQL находится под архитектурой ARM. 8.0 Проблемы с нажатием воспроизведения на мобильных телефонах,когда При открытии commit_order,При параллельном воспроизведении MySQL архитектуры ARM одновременно работает только 1 SQL-поток.существоватьARMПод структурой,когда Когда уже есть повтор транзакции,системный вызов sysconf Может быть возвращено при получении размера строки кэша ЦП. 0, что приводит к Commit_order_manager Невозможно добавить рабочий поток ID подтолкнуть к Commit_order_queue середина. Однако, судя по ответам об ошибках, официальные лица MySQL, похоже, не признают существования этой проблемы.

Хотя чиновник не признает эту проблему, TXSQL не признает, что решил эту проблему. Но на самом деле у MySQL есть эта проблема, и TXSQL ее решает.

Затем сравните коды TXSQL и MySQL, и вы сразу поймете.

Ниже приведен соответствующий код для общественной версии MySQL 8.0.28.

aligned_atomic.h:78
<<<
#elif defined(__linux__)
static inline size_t _cache_line_size() {
  return sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
}

Не удобно выкладывать код TXSQL. Вот код MySQL 8.0.35 для сравнения. (Да, вы правильно прочитали, MySQL исправила эту ОШИБКУ в последней версии MySQL 8.0.35, выпущенной 25 октября, хотя в примечаниях к выпуску описано, что это было сделано для решения неожиданной проблемы простоя MySQL; и версия этого исправления от TXSQL. ​на основе исправлений компиляции~)

#elif defined(__linux__)
static inline size_t _cache_line_size() {
  long size = sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
  if (size == -1) return 64;

  // returns 0 on s390x RHEL 7.x and some __arch64__ configurations.
  if (size == 0) {
    FILE *p = fopen(
        "/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size", "r");
    if (p) {
      if (fscanf(p, "%ld", &size) != 1) size = 0;
      fclose(p);
    }
  }

  if (size > 0) return static_cast<size_t>(size);
  return 64;
}

Исправление здесь тоже выглядит простым,Когда системный вызов sysconf для получения кэша_линии_размера ЦП возвращает 0,Только что из/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_sizeценить。

Я изменил MySQL на основе приведенного выше кода восстановления. Код, связанный с 8.0.28, после перекомпиляции под архитектуру ARM, версия MySQL сообщества по тому же бизнес-сценарию. Скорость воспроизведения из библиотеки в 8.0.28 можно увеличить до 5.14к insert + 5.14k update= 10.28K/S,Скорость увеличена в 3 раза по сравнению с доремонтом, что эквивалентно скорости воспроизведения ведомой библиотеки X86.。и,График пламени отремонтированной ведомой библиотеки ARM в основном такой же, как и у ведомой библиотеки X86.

На этом этапе большая проблема задержки репликации из базы данных для версии MySQL сообщества под архитектурой ARM наконец-то устранена. Версия MySQL, созданная сообществом, имеет ошибку совместимости в функции получения размера строки кэша ЦП в архитектуре ARM, что приводит к фиксации. orderСценарий блокировки очереди транзакций,В результате, несмотря на наличие нескольких SQL-поток, одновременно активен только один поток.,Это серьезно ограничивает скорость воспроизведения SQL и вызывает задержки в подчиненной базе данных при высокой нагрузке.

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