Разработчик TiDB здесь.
Согласно вашему описанию, ваш сценарий представляет собой сценарий между центрами обработки данных на большие расстояния.В таких сценариях вы должны понимать, что при таком развертывании ваша задержка чтения и записи будет сильно зависеть от задержки между вашими центрами обработки данных.
Более разумное развертывание: если ваша рабочая нагрузка в основном находится в Европе, и вам требуется высокая согласованность и высокая доступность одновременно, тогда вы можете выбрать два IDC в Европе и 1 IDC в Австралии для развертывания TiDB,и ваше приложение должно быть развернуто в Европе.Потому что для tidb запись требует, чтобы большинство реплик были записаны успешно.В этом сценарии задержка записи составляет:
latency = min(latency(IDC1, IDC2), latency(IDC2, IDC3), latency(IDC1, IDC3)）
Вот несколько предложений по развертыванию и сравнение для различных сценариев:
1.Решение по развертыванию 3-DC
TiDB, TiKV и PD распределяются между 3 DC.
Преимущества:
Все реплики распределены между 3 DC.Даже если один DC не работает, другие 2 DC инициируют выборы лидера и возобновляют обслуживание в течение разумного периода времени (в большинстве случаев в течение 20 с), и данные не теряются.Для получения дополнительной информации см. Следующую диаграмму:
Недостатки:
Производительность сильно ограничена задержкой в сети.
Для записи:все данные должны быть реплицированы как минимум на 2 DC.Поскольку TiDB использует двухфазную фиксацию для записи, задержка записи по меньшей мере вдвое превышает задержку сети между двумя DC.
Производительность чтения также пострадает, если лидер не находится в том же DC, что и узел TiDB сзапрос на чтение.
Каждая транзакция TiDB должна получить Oracle TimeStamp (TSO) от лидера PD.Таким образом, если TiDB и лидер PD находятся не в одном DC, на производительность транзакций также будет влиять задержка сети, поскольку каждая транзакция с запросом на запись должна будет дважды получать TSO.
Оптимизации:
Если не все три контроллера домена нуждаются в обслуживании приложений, вы можете отправить все запросы на один контроллер домена и настроить политику планирования для переноса всехЛидер TiKV Region и лидер PD в том же округе, что мы сделали в следующем тесте.Таким образом, задержка сети между контроллерами домена не повлияет ни на получение TSO, ни на чтение регионов TiKV.Если этот DC не работает, лидер PD и региональный лидер будут автоматически избраны в других выживших DC, и вам просто нужно переключить запросы на DC, которые все еще в сети.
2.Решение по развертыванию 3-DC в 2 городах
Это решение аналогично предыдущему решению по развертыванию 3-DC и может рассматриваться как оптимизация на основе бизнес-сценария.Разница в том, что расстояние между двумя DC в одном и том же городе невелико, и, следовательно, задержка очень мала.В этом случае мы можем отправлять запросы двум DC в одном городе и настраивать лидера TiKV и PD, чтобы он находился в 2 DC в одном городе.
По сравнению с развертыванием 3-DC, развертывание 3-DC в 2 городах имеет следующие преимущества:
- Лучшая производительность записи
- Лучшее использование ресурсов, поскольку 2 DC могут обеспечитьсервисы для приложений.
- Даже если один DC не работает, кластер TiDB все еще будет доступен, и данные не будут потеряны.
Однако недостатком является то, что, если 2 DC в одном и том же городе выйдут из строя, вероятность которых выше, чем вероятность сбоя 2 DC в 2 городах, кластер TiDB будет недоступен инекоторые данные будут потеряны.
3.Решение по развертыванию синхронизации 2-DC + Binlog
Синхронизация 2-DC + Binlog аналогична решению MySQL Master-Slave. 2 полных набора кластеров TiDB (каждый полный набор кластера TiDB включает в себя TiDB, PD и TiKV) развернуты в 2 DC, один действует как ведущий, а другой - как ведомый. В обычных условиях главный DC обрабатывает все запросы, и данные, записанные в главный DC, асинхронно записываются в подчиненный DC через Binlog.
Если главный DC отключается, запросы могут переключаться на подчиненный кластер. Как и в MySQL, некоторые данные могут быть потеряны. Но в отличие от MySQL, это решение может обеспечить высокую доступность в одном и том же DC: если некоторые узлы в DC не будут работать, это не повлияет на онлайн-бизнес и не требует никаких ручных усилий, поскольку кластер автоматически переизбирает лидеров для оказывать услуги.
Некоторые из наших производственных пользователей также используют мультиактивное решение 2-DC, что означает:
- Запросы приложений разделяются и отправляются в 2 контроллера домена.
- Каждый DC имеет 1 кластер, и каждый кластер имеет две базы данных: базу данных Master, которая обслуживает часть запросов приложений, и базу данных Slave, которая служит резервной копией базы данных Master другого DC. Данные, записанные в базу данных Master, синхронизируются через Binlog с базой данных Slave на другом DC, образуя цикл резервного копирования.
Обратите внимание, что для решения синхронизации 2-DC + Binlog данные асинхронно реплицируются через Binlog. Если задержка сети между двумя DC слишком высока, данные в подчиненном кластере будут сильно отставать от главного кластера. Если основной кластер выйдет из строя, некоторые данные будут потеряны, и нельзя гарантировать, что потерянные данные находятся в течение 5 минут.
Общий анализ для HA и DR
Для решения по развертыванию 3-DC и решения 3-DC в 2 городах мы можем гарантировать, что кластер будет автоматически восстанавливаться, никакого вмешательства человека не требуется и что данные строго согласованы, даже если один из 3 DC выходит вниз. Все политики планирования предназначены для настройки производительности, но в случае сбоя приоритет имеет доступность 1, а не производительность.
Для решения по синхронизации 2-DC + Binlog мы можем гарантировать, что кластер будет автоматически восстановлен, никакого вмешательства человека не требуется, и что данные будут строго согласованы, даже если какой-либо из узлов в мастер-кластере выйдет из строя. Когда весь мастер-кластер выйдет из строя, потребуются ручные усилия для переключения на ведомый, и некоторые данные будут потеряны. Количество потерянных данных зависит от задержки сети и определяется состоянием сети.
Рекомендации по достижению высокой производительности
Как описано ранее, в сценарии с 3-мя DC задержка сети очень важна для производительности. Из-за высокой задержки транзакция (10 операций чтения на 1 запись) займет 100 мс, а один поток может достичь только 10 TPS.
Эта таблица является результатом нашего теста Sysbench (3 IDC, 2 US-West и 1 US-East):
| threads | tps | qps |
|--------:|--------:|---------:|
| 1 | 9.43 | 122.64 |
| 4 | 36.38 | 472.95 |
| 16 | 134.57 | 1749.39 |
| 64 | 517.66 | 6729.55 |
| 256 | 1767.68 | 22979.87 |
| 512 | 2307.36 | 29995.71 |
| 1024 | 2406.29 | 31281.71 |
| 2048 | 2256.27 | 29331.45 |
По сравнению с ранее рекомендованным развертыванием, согласно которому лидеры региона TiKV должны находиться в одном DC, приоритет лидера PD устанавливается pd-ctl member leader_priority pd1 2, чтобы установить лидера PD в том же DC лидеров региона TiKV , избегая чрезмерно высокой задержки в сети при получении TSO.
Исходя из этого, мы заключаем, что если вы хотите использовать больше TPS, вам следует использовать больше параллелизма в вашем приложении.
Мы рекомендуем следующие решения:
- Добавьте больше экземпляров TiDB с той же конфигурацией для дальнейшего тестирования, чтобы использовать масштабируемость TiDB.
- Чтобы избежать снижения производительности, вызванного запросами на фиксацию транзакций между контроллерами домена, рассмотрите возможность изменения рабочей нагрузки с
10 reads + 1 write для каждой транзакции на 100 reads + 10 writes для более высокого QPS.
На вопрос о HA ответ заключается в том, что в случае сбоя контроллера домена не требуется ручная операция.Это происходит потому, что даже если DC лидера выходит из строя и лидеры блокируются в одном DC, большинство реплик все еще выживает и выберет нового лидера после сбоя благодаря алгоритму согласования Raft.Этот процесс автоматический и не требует ручного вмешательства.Служба все еще доступна и не будет затронута, только с небольшим снижением производительности.