Почему мы переходим с MySQL на TiDB?

база данных
Почему мы переходим с MySQL на TiDB?

Эта статья воспроизведена из публичного аккаунтаТехнологический стек 51CTO.

об авторе: Хэ Лей, старший инженер по эксплуатации и обслуживанию базы данных 360, «автор эксплуатации и обслуживания MongoDB», известный модератор форума MySQL, звезда блога 51CTO, в свободное время он любит писать некоторые случаи в виде блогов, и общее число посещений превышает один миллион.

Позвольте мне начать с нескольких моментов, которые волнуют и радуют вас больше всего:

  • В TiDB вам вообще не нужно беспокоиться о емкости диска.

  • В TiDB изначально поддерживается Online DDL, поэтому вам не нужно беспокоиться о всевозможных ошибках в сторонних инструментах модификации таблиц.

  • В TiDB добавление столбцов и полей раскрытия первичного ключа происходит за считанные секунды.Например, я только что добавил поля в таблицу из 1,9 миллиарда, и это было сделано за 1 секунду.В MySQL требуется 8.0, а также требуется, чтобы перечислены в Наконец.

  • В TiDB вы обнаружите, что count(*) работает на удивление быстро.Таблица из почти 2 миллиардов count(*) может быть завершена примерно за 1 минуту.Конечно, это зависит от вашего числа KV и производительности диска.

  • В TiDB миграция с MySQL станет проще, графическая миграция в один клик, это круто?

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

  • В ТиДБ... ты посмотри вниз, я тебе потихоньку скажу.

использовать фон

Облачная платформа 60 обеспечивает сервисную поддержку для всех основных направлений бизнеса группы 360. Задействованные решения по поддержке баз данных включают: MySQL, Redis, MongoDB, ES, GP и PiKA.

Среди них экземпляров MySQL на данный момент более 10 000. В настоящее время существуют узкие места для некоторых предприятий с большим объемом написания.

Например, место на диске, хотя мы можем разделить его по подбазам и подтаблицам, это очень много работы для бизнеса и DBA, и самое мучительное — менять эти большие таблицы.

Будь то T в одной таблице или подбазе данных и подтаблице, стоимость выполнения DDL для большой таблицы очень высока.

В ответ на взрывной рост объема данных бизнеса мы начали исследовать, существуют ли другие базы данных, которые могут заменить традиционную MySQL.

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

На данный момент на облачной платформе 360 имеется три набора кластеров TiDB, а общее количество узлов составляет 50+. Подключено и используется 9 направлений бизнеса, есть случаи онлайн добавления десятков миллиардов таблиц, а общий объем данных на данный момент составляет 80T.

Что касается версии, мы прошли весь путь от 3.0.1 до 3.0.5, версия DM прошла путь от внутреннего тестирования до версии 1.0.2 GA, и в общей сложности для отзывов было отправлено 9 ошибок или элементов улучшения.

В будущем мы планируем разместить TiDB на облачной платформе 360 HULK и настроить некоторые функции для предоставления визуальных услуг для бизнеса, чтобы больше бизнес-направлений 360 Group могли получить доступ и использовать TiDB.

Причина, по которой мы начали с версии 3, заключается в том, что мы видели некоторые отзывы сообщества о версии 2.X, особенно о плане выполнения индекса.Версия 3.X будет намного лучше, чем предыдущая версия. Версия DM — это последняя версия, которую мы выбрали напрямую, и мы будем следовать новой версии для полного обновления.

Кластерная архитектура

В общей архитектуре, помимо кластера TiDB, мы также использовали пакеты DM, Pump и Drainer.

В основном это связано с тем, что мы используем TiDB для двух предприятий:

1. Старый бизнес MySQL

Старый бизнес MySQL ограничен диском с одной машиной, поэтому диск с одним экземпляром не может поддерживать взрывной рост объема данных.Данные важнее и нуждаются в резервном копировании и поддержке 7 * 24 часов восстановления.

Для этого типа бизнеса мы используем пакет DM для обеспечения безбарьерной миграции.Время импорта 1 ТБ составляет 16 часов.Если это относительно большой источник данных и TiDB является совершенно новым кластером, можно использовать TiDB Lightning, и скорость может быть выше.

Измеренная скорость импорта Lightning составляет 37 минут.После импорта 2 больших таблиц в общей сложности 54G данных соответствует оценке 100G/H, что в 3 раза превышает скорость загрузчика.Загрузчик занимает 2 часа и 4 минут.

Говоря о DM с помощью этой статьи, мы поделимся вопросами, требующими внимания, позже, как показано на следующем рисунке:

2. Совершенно новый бизнес

Совершенно новый бизнес или импортированный в кластер TiDB бизнесом, как правило, имеет относительно большой объем данных, и ему также нравятся ACID и распределенные функции TiDB.

В настоящее время в бизнесе NetShield есть много таблиц, которые превышают 1 миллиард уровней, а одна из них достигла 10 миллиардов+, и на построение индекса ушло почти 10 дней (на самом деле, мы должны обратить на это внимание, если это не распространяется, будет делаться с одной таблицей, т.к. масштаб таблицы слишком большой, очистка старых данных - проблема).

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

Использование TiDB в облачной платформе 360

Для этой совершенно новой базы данных мы используем ее смело и не придерживаемся традиционного подхода. Наш MySQL сейчас также адаптируется к версии 8.0, и MongoDB и ES также всегда обращают внимание на новую версию, чтобы оценить, подходит ли она для облачной платформы.

Поэтому запуск TiDB — это еще и переход от офлайн-бизнеса к периферийному бизнесу к основному бизнесу.

После долгих испытаний и со ссылкой на использование другими компаниями мы планируем включить TiDB в облачную платформу 360 HULK и планируем в будущем постоянно улучшать ее функции на облачной платформе, делая ее доступной для всего направления деятельности компании.

Индивидуальная разработка некоторых MySQL, таких как аудит SQL, статистика медленных запросов, обнаружение избыточного индекса, пороговое значение индекса с автоматическим приращением и другие основные функции.

Хотя во время использования мы столкнулись с некоторыми небольшими проблемами, такими как выбор индекса, настройка параметров и дрожание производительности, вызванное некоторыми конфигурациями, мы получили быстрые ответы и ответы от студентов PingCAP, что очень помогло нам в продвижении TiDB.

Инструмент миграции в один клик

Опыт ДМ таков:

1. Разрешения

В официальном руководстве веб-сайта только указано, что требуются следующие разрешения:

TiDB Lightning требует следующих разрешений:

  • SELECT

  • UPDATE

  • ALTER

  • CREATE

  • DROP

Для базы данных, в которой хранятся точки останова, дополнительно требуются следующие разрешения:

  • INSERT

  • DELETE

Однако в ходе фактического теста было обнаружено, что требуются следующие разрешения:

  • Восходящий поток (необходимо иметь разрешение REPLICATION SLAVE, в противном случае добавочная синхронизация будет запрещать доступ).

  • Вниз по течению (без super таблица контрольных сумм не может быть выполнена).

2. TiKV Rezcore

В мониторинге PD -Statistics-balance есть элемент мониторинга Store-region-score, который записывает баллы Score каждого узла.В нормальных условиях мы ожидаем, что результаты будут близки друг к другу, что означает, что крупномасштабная миграция Регионов не требуется.

3. Принцип планирования ПД

Планирование балансировки нагрузки региона в основном зависит от двух планировщиков: Balance-Leader и Balance-Region.

Цель планирования этих двух — равномерно распределить регионы по всем магазинам в кластере, но у них есть свои приоритеты:

  • Баланс-лидер обращает внимание на Лидера региона, чтобы разогнать нагрузку по обработке клиентских запросов.

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

Здесь мы фокусируемся на области баланса.Когда он несбалансирован, мы можем непосредственно увидеть что-то вроде следующего рисунка в мониторинге:

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

Поэтому у нас есть два момента, на которые стоит обратить внимание:

  • Как контролировать или снизить влияние на бизнес при масштабной миграции Регионального баланса;

  • Как заранее избежать крупномасштабного баланса регионов, вызванного дисками.

Во-первых, у нас есть параметры, которыми нужно управлять при миграции. Будь то пороговое значение дискового пространства, скорость планирования баланса регионов или скорость корректировки слияния пустых регионов после удаления большого количества таблиц, их можно настроить в режиме реального времени с помощью команды config set команды pd-ctl.

Например:

  • high-space-ratio 0.7 #Установите порог достаточного пространства равным 0,7. Когда коэффициент занятости узла меньше указанного значения, PD игнорирует индикатор оставшегося пространства во время планирования PD и балансирует фактический объем данных.

  • region-schedule-limit 8 # Максимум 8 регионов могут быть запланированы одновременно. Это значение в основном влияет на скорость баланса регионов. Чем больше значение, тем быстрее выполняется планирование. Если установлено значение 0, планирование будет отключено. Планирование региона имеет большие накладные расходы, поэтому это значение не следует устанавливать слишком большим. Вы также можете ограничить влияние регионов планирования на кластер, уменьшив это значение.

  • merge-schedule-limit 12 # До 12 расписаний слияния одновременно. Установите значение 0, чтобы отключить слияние регионов. Планирование слияния имеет большие накладные расходы, поэтому это значение не следует устанавливать слишком большим.

  • Leader-schedule-limit 8 # Максимум 8 лидеров могут быть запланированы одновременно. Это значение в основном влияет на скорость баланса лидеров. Чем больше значение, тем быстрее происходит планирование. Если установлено значение 0, планирование будет отключено. Накладные расходы на планирование Лидера невелики, и при необходимости их можно соответствующим образом скорректировать.

  • max-merge-region-keys 50000 #Установите верхний предел keyCount для слияния регионов на 50 тыс.. Когда значение Region KeyCount больше указанного значения, PD не будет объединять его с соседними регионами.

  • max-merge-region-size 16 # Установите верхний предел размера слияния регионов на 16M. Когда Размер региона больше указанного значения, PD не будет объединять его с соседними регионами. Установите значение 0, чтобы отключить функцию слияния регионов.

TIPS: После понимания функции и принципа вышеуказанные параметры можно контролировать в соответствии с потребностями.

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

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

Поэтому мы хотели бы выполнить слияние регионов как можно скорее, чтобы избежать слишком большого количества регионов, вызывающих потерю производительности кластера.Мы можем одновременно уменьшить max-merge-region-keys и max-merge-region-size, чтобы сделать их быстрее. операцию слияния и увеличьте лимит расписания слияния, чтобы улучшить параллелизм.

Например, когда мы обнаруживаем, что 40% дискового пространства KV осталось для запуска большого количества планировщиков, мы можем скорректировать high-space-ratio до 0,7, чтобы временно избежать влияния планирования на бизнес.

Мы также можем контролировать параллелизм планирования, чтобы уменьшить влияние на бизнес.Фактическое измерение является немедленным параметром.Если вы столкнетесь с этими проблемами, вы можете обратиться к нему.

По второму пункту, особенно при использовании DM, когда DM-worker и TiKV развернуты вместе, обратите внимание на очистку файлов и Relaylog, оставленных полным бэкапом.

Стратегия планирования по умолчанию заключается в том, что, когда оставшееся эффективное пространство на диске составляет менее 40 %, и в промежуточном состоянии как объем данных, так и оставшееся пространство рассматриваются как взвешенная сумма в качестве оценки. в партитуре начнется планирование.

Поэтому после завершения импорта DM не забудьте удалить полную резервную копию. Это папка dumped_data.task_xxx. Эта полная резервная копия обычно имеет большой размер. Если dm-worker и TiKV расположены вместе, может показаться, что скорость использования диска узла TiKV выше, чем у других.

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

Подождав, пока он нагонит, это будет выглядеть следующим образом:

В этот момент балансировщик достиг сбалансированного состояния:

Продолжительность возвращается к нормальному уровню, как показано ниже в 16:54:

QPS больше не задерживается и возвращается к нормальному уровню:

Что касается relay-log, то он по умолчанию не очищается, как и expire_logs_days в MySQL, который можно настроить через файл конфигурации dm-worker.

Например, настройте Expires на 7, что означает, что он будет удален через 7 дней:

[purge]
interval = 3600
expires = 7
remain-space = 15

Истекает для контроля дней хранения. По умолчанию expires=0, то есть время истечения отсутствует, а оставшееся пространство=15 означает, что когда на диске останется всего 15G, он начнет пытаться очиститься, с такой ситуацией мы сталкиваемся редко, поэтому данный способ очистки в принципе бесполезен прибыл.

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

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

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

Если dm-worker и TiKV расположены вместе, файлы полной резервной копии будут занимать большой объем дискового пространства, что приведет к ненормальным оценкам региона TiKV, что приведет к снижению производительности, что было преобразовано в требования продукта PRM.

4. О проблеме потери данных при использовании DM

В первые дни, когда dm-portal не генерировал задачи автоматически, мы все сами писали файлы синхронизации задач DM. Позже, с помощью инструмента автоматической генерации dm-portal, если на нем немного страницы с графикой.

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

Это будет выглядеть так, что когда MySQL верхнего уровня заново создаст таблицу, нижний поток будет проигнорирован.Например, когда вы используете инструмент изменения таблицы gh-ost или pt-online-schema-change, ваша временная таблица будет рассматриваться как не белый.Список игнорируется и пользователи должны обратить внимание на эту проблему.

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

["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD COLUMN `raw_url_md5` CHAR(32) NOT NULL DEFAULT '' COMMENT 'raw_url md5'"]
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD INDEX `idx_rawurl_md5`(`raw_url_md5`)"] [schema=flow]
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` DROP INDEX `idx_raw_url`"] [schema=flow]

Журнал здесь показывает, что событие было пропущено.

5. О случайном конфликте первичного ключа 1062 во время использования DM

Задача запроса-ошибки может видеть конкретную информацию об ошибке, а нижестоящее представление не имеет этого значения:

mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';
Empty set (0.00 sec)

Снова переходя к апстриму, оказывается, что значения нет, а бизнес-логику нужно удалить позже:

mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';
Empty set (0.00 sec)

Поскольку в восходящем потоке нет значения, перейдите в восходящий поток, чтобы увидеть Binlog и проанализировать его следующим образом:

Он сначала записывается, а затем удаляется, поэтому ожидается, что восходящий поток не имеет значения, но нисходящий поток не был синхронизирован с этим блоком, и в это время значения нет, поэтому проблемы 1062 быть не должно.

Когда в кластере возникает крупномасштабная ошибка kv:1062 или когда кластер находится под сильным давлением записи, DM не может гарантировать упорядоченное размещение бинлога по результатам.Необходимо подтвердить, может ли DM гарантировать, что Каждое событие из нескольких журналов TiDB Binlog в LVS выполняется по порядку.

Только из-за явления, пока в кластере нет большого количества ошибок 1062, значения мониторинга, связанные с PD, относительно низкие, и DM не будет иметь синхронных ошибок, и наоборот.

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

Решение состоит в том, чтобы разделить 1062 конфликтующих сервиса из кластера, или DM напрямую пишет реальный IP TiDB вместо LVS.

6. Исключение синхронизации DM

Исключение синхронизации возникает, когда есть деловая обратная связь. Удаление раздела и столбца. Добавьте результаты теста, относящиеся к таблице разделов.DM еще более неспособен к разбиению в разделе Drop.Обычные добавить и изменить не проблема.

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

alter table dsp_group_media_report drop partition p202006 ,p202007 ;

Операция Drop для столбца с индексом сообщит об ошибке:

Alter table dsp_group drop column test_column;

Длительность увеличивается за счет добавления DDL к 4 миллиардам таблиц и добавления индексов:

Найдите, чтобы:

mysql> show global variables like 'tidb_ddl_reorg_worker_cnt';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| tidb_ddl_reorg_worker_cnt | 16    |
+---------------------------+-------+
1 row in set (0.11 sec)

mysql> show global variables like 'tidb_ddl_reorg_batch_size';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| tidb_ddl_reorg_batch_size | 1024  |
+---------------------------+-------+

Вышеупомянутые два параметра оказывают большое давление на существующие кластеры без PCI. Скорректировано set global (после 3.0.3 значение по умолчанию увеличилось с 256 до 1000 и 16):

tidb_ddl_reorg_batch_size 1000-256
tidb_ddl_reorg_worker_cnt 16-4

В то же время улучшите уплотнение, связанное с:

max-background-jobs: 8-10-12
max-sub-compactions: 1-2-4
defaultcf.compression-per-level: ["lz4", "lz4", "lz4", "lz4", "lz4", "zstd", "zstd"]
writecf.compression-per-level: ["lz4", "lz4", "lz4", "lz4", "lz4", "zstd", "zstd"]

Окончательный результат оптимизации заключается в том, что QPS стабильно составляет около 3K:

7. Тихая область включена

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

Затем вы можете свести к минимуму количество сообщений во временно простаивающих регионах, что является функцией спящих регионов.

Raft-base-tick нельзя выполнять, когда в этом нет необходимости, то есть не будет управляться конечный автомат Raft простаивающих регионов, тогда Raft этих регионов не будет запускаться для генерации информации heartbeat, что значительно снижает нагрузку на Рафтстор.

Начиная с TiDB v3.0.5, область гибернации по-прежнему является экспериментальной функцией и включена по умолчанию в основной ветке TiKV. Эта функция может быть включена в соответствии с реальной ситуацией и потребностями.

Параметры следующие:

raftstore.hibernate-regions: true

8. Увеличена продолжительность при импорте DM

Во время импорта DM в кластер общая длительность кластера действительно будет выше из-за проблемы с точками доступа для записи, поскольку конкуренция за ввод-вывод будет более очевидной. На самом деле некоторые параметры можно использовать для ускорения работы кластера.

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

raftstore:
apply-pool-size: 3-4
store-pool-size: 3-4

storage:
scheduler-worker-pool-size: 4-6

server:
grpc-concurrency: 4-6

rocksdb:
max-background-jobs: 8-10
max-sub-compactions: 1-2

Видно, что эффект следующий: QPS больше не дрожит, а Duration возвращается к нормальному уровню.

9. Отладка DM, связанная с

Еще один момент, который следует отметить в DM, это то, что конфигурация log-level="debug" в файле конфигурации dm-worker.toml не действует.При запуске по умолчанию есть опция -L=info, которая перезапишет конфигурацию. По умолчанию -L Приоритет выше, чем у файла конфигурации, и он запускается автоматически во время проверки вручную.

То есть, когда вам нужно включить режим отладки для dm-worker, вам нужно вручную запустить процесс и указать -L option=debug.

10. Скорость загрузки данных TiDB не идеальна

В настоящее время скорость импорта данных загрузки TiDB не такая высокая, как у MySQL.Если вы полагаетесь на данные загрузки, вы можете настроить параметры в этом разделе.

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

storage:
scheduler-concurrency: 204800000

raftstore:
raft-max-inflight-msgs: 4096

После завершения настройки есть улучшение, но улучшение не большое.Мы знаем, что в новой версии TiDB есть улучшение скорости в разделе Load data, и мы с нетерпением ждем новой версии.

Упаковка и доля других галантереи

1. Количество столбцов TiDB превышает лимит

MySQL — 1024, а TiDB в настоящее время ограничен 512 столбцами. Если в вашей таблице много столбцов, вам следует заранее обратить внимание на возможность их разделения.

2. GC can not work

Данные GC включают две части, одна часть — DML и DDL, информация об объекте GC DDL включена в mysql.gc_delete_range и mysql.gc_delete_range_done, которые соответственно записывают объекты, которые должны быть GC, и объекты, которые были GC. Отсутствие данных в таблице mysql.gc_delete_range_done не означает, что сборка мусора ненормальна.

Официальное предложение по замене правил:

sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d]))

3. TiDB или условная оптимизация

В TiDB следующие запросы не могут использовать индексы:

select * from manual_domain where host_md5  = '55fbea39965484a61xxxxxxxxxx'  or domain_md5 = '55fbea39965484a61xxxxxxxxxx';

MySQL использует index_merge, который поддерживается планом TiDB 4.0.Вы можете использовать union all, чтобы сначала обработать это a или b.

4. Слишком высокая загрузка процессора сопроцессором

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

Перейдите к машине с высокой загрузкой ЦП, чтобы найти соответствующий журнал, ключевое слово медленно, и найдите следующее:

[2019/09/18 10:04:37.339 +08:00] [INFO] [tracker.rs:150] [slow-query] [internal_key_skipped_count=46649] [internal_delete_skipped_count=0] [block_cache_hit_count=1596] [block_read_count=9] [block_read_byte=31933] [scan_first_range="Some(start: 7480000000000002285F72800000000021E9BD end: 7480000000000002285F72800000000024199A)"] [scan_ranges=1] [scan_iter_processed=46650] [scan_iter_ops=46652] [scan_is_desc=false] [tag=select] [table_id=552] [txn_start_ts=411244239493267464] [wait_time=2ms] [total_process_time=1.41s] [peer_id=ipv4:192.168.1.248:45686] [region_id=835437]

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

Проблемы с производительностью, вызванные перечислением TiDB:

Когда перечисление выполняет условный поиск where в TiDB 3.0.2, обнаруживается, что его нельзя передать в TiKV. Официальные лица говорят, что исправления 4.0GA. Временным решением является изменение на другие типы.

Модификация enum обнаруживает, что содержимое для tinyint изменилось. Исходное '' стало значением по умолчанию, а '1' стало 2. После тестирования varchar в норме. Поэтому не пытайтесь изменить файл схемы, зарезервированный DM для реализации изменения структуры таблицы. Решено из вышестоящей MySQL.

5. Не удается получить метаданные таблицы разделов

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

Секционированная таблица - некоторые разделы - ограничение не снижено: ограничение не проталкивается вниз в таблице разделов, и только раздел p201911 имеет данные в таблице content_info_p. Эта проблема была исправлена ​​в версии 3.0.6.

Исключение разрешения таблицы mysql.tidb: После указания имени БД с помощью use db_name или клиента mysql вы можете запросить или обновить таблицу. Запланировано исправление версии 3.1.

предел вещей: SQL-оператор одной транзакции не может превышать 5000 (параметр stmt-count-limit настраивается); каждая пара ключ-значение не может превышать 6M; общее количество пар ключ-значение не может превышать 300 000; общий размер пар значений не может превышать 100M.

Примечание. Пара ключ-значение означает, что в таблице есть 2 индекса, тогда общее значение равно значению + 2 индекса, всего 3 пары ключ-значение, тогда каждая пара ключ-значение никогда не может превышать 300 000/3 = 100 000. .

Строка данных будет сопоставлена ​​с записью KV, и каждый дополнительный индекс также будет добавлять запись KV, поэтому это ограничение отражается на уровне SQL: общее количество строк * (1 + количество индексов)

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

  • tidb_batch_insert

  • tidb_batch_delete

  • tidb_dml_batch_size

Обработка горячих точек записи.

Подробную информацию см. во введении SHARD_ROW_ID_BITS в системных переменных и синтаксисе, специфичных для TiDB, на официальном веб-сайте.

6. Мониторинг TiDB и мониторинг DM Конфликт данных развертывания Ansible

Это можно обойти, развернув мониторинг TiDB и DM на разных машинах, иначе окажется, что после установки Ansible, когда ansible-playbook roll_update_monitor.yml --tags=prometheus, только один из двух является нормальным.

Используемый диск не рекомендуется превышать 50%: Объем данных слишком велик, а LSM слишком велик, стоимость уплотнения будет высокой, а скорость попадания в память снизится.В то же время время восстановления одной машины очень велико, около 50% является лучшим, а скорость использования слишком высока.Если произойдет внезапное увеличение количества операций записи, регион не сможет планировать встречи Полный диск, рискованно.

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

7. Mydumper вызывает переполнение памяти и сетевой карты

При использовании Mydumper для резервного копирования большого тома сетевая карта TiDB будет заполнена, и одновременно будет потребляться больше памяти TiDB и TiKV.

TiDB ERR】[emergency]TiDB_schema_error:192.168.1.1:10080,[add_dba_mysql]【360】
【TiDB ERR】[critical]NODE_memory_used_more_than_80%:192.168.1.2:9100,[add_dba_mysql]【360】

Чтобы получить медленный журнал, вы увидите следующее:

grep Query_time tidb_slow_query-2019-12-24T04-53-14.111.log|awk -F : '$2>10'
# Time: 2019-12-24T03:18:49.685904971+08:00
# Txn_start_ts: 413433784152621060
# User: backup@192.168.1.3
# Conn_ID: 4803611
# Query_time: 4002.295099802
SELECT /*!40001 SQL_NO_CACHE */ * FROM `360`.`t_d` ;

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

Перспектива

Мы начали тестирование с TiDB 2.x, и окончательно выбранная версия — 3.0.2, позже она будет обновлена ​​до 3.0.5.

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

Команда DBA облачной платформы 360 также планирует разместить TiDB на облачной платформе 360 HULK, чтобы предоставлять красочные, стабильные и надежные услуги баз данных для большего количества направлений бизнеса 360 Group.

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

При этом я сам читал официальный мануал TiDB. От развертывания Ansible, развертывания бинарных файлов, обновления, DM, Lighting, Pump, Drainer, настройки, устранения неполадок, миграции, резервного копирования, вплоть до борьбы с монстрами, я лично чувствую, как процесс TiDB становится все лучше и лучше.

Я считаю, что с выпуском версий 3.1 и 4.0 в будущем к команде, использующей TiDB, присоединится больше людей.

Отзывы, полученные от бизнеса, также удовлетворены использованием TiDB.Мы верим, что TiDB будет становиться все лучше и лучше благодаря совместным усилиям всех.

Категории