Во-первых, задержка от мастер-копии
Где :( 1 https://blog.csdn.net/u010522235/article/details/51865978)
основная библиотека DDL (изменить, падение, ремонта, создать ) задержка в результате чего узла только для чтения
могущества 1: только для чтения узла первичной базы данных синхронизация осуществляется последовательный DDL, операции DDL , если долгое время выполнения основных библиотек, может потреблять в то же время в процессе подготовки библиотеки, например, в виде таблицы главной базы данных , чтобы добавить поле к 500W занимают 10 минут, а затем на узле чтения будет также занимает 10 минут, так что 600S задержки узел только для чтения, другие общие операции , такие как:
колонка MySQL> Н.Н. изменить Добавить таблицу Test VARCHAR (10);
MySQL> Таблица Тест ALTER индекс Добавить (JJ);
возможно 2: существует очень много времени , чтобы выполнить запрос выполняются на узле только для чтения, этот засорить DDL - запрос от главной библиотеки, чтения таблица узла не будет заблокирована до конца запроса, что привело к задержке данных только для чтения узлов. Может быть просмотрено на узле чтения , подключенном с помощью выполнения команды состояния является шоу PROCESSLIST: Ожидание блокировки метаданных таблицы
Решение:
Для 1 может быть, можно только сказать , что перед операцией может привести воздействие на рассмотрели, в случае 2, может убить большие запросы на узле только для чтения, вы можете восстановить данные только для чтения узлов и главного узел синхронный
Для бинарных журналов, из-за своего времени записи происходит, когда сделка совершается, то предполагается, что производит двоичный журнал 1G, вы должны представить время транзакции будет включать в себя время, записывается журнал 1G. Существует поговорка, в Oracle, сделка представляется являются фиксированная ставка, независимо от размера сделки. Это база данных MySQL не установлена. То есть, MySQL двоичная скорость подачи зависит от размера журнала транзакций генерируется, скорость сделки совершает не является плоским.
Хуже того, MySQL, ведущая-ведомая задержка репликации под крупной сделкой. Также предположим, что крупная сделка выполняется один час на первичном сервере, вам нужно передать с сервера в конце периода подачи. От главной задержки в худшем случае, по крайней мере, одного часа, при необходимости с сервера выполняет один час, то задержка от мастер-копии может быть 2 часа. Такие ограничения не существуют физически скопированы или причина описаны выше, операция фиксации процесса, журнал был передан и воспроизведение.
Короче говоря, для базы данных MySQL, время не допускает большое выполнения транзакций. Для этого, крупная сделки разделена на небольшую подтранзакцию для выполнения. Это основные различные формулы, и все же имеет очень разные и Oracle. Короче говоря, Airbender, Gladius, ничего хорошего или плохого, научиться понимать различия, искусности площадь до, как Чжэнь Фэн Цинян области.
Если следовать основные формулы, разделить крупные сделки небольшие сделки, MySQL не будет иметь особенно большую задержку с O-резьбой сервера ввода /. Однако SQL задержка нить еще не может быть решена.
В начале MySQL5.6, введение параллельной копии, эта копия является одновременно уровнем базы данных, что означает, что SQL нить может обрабатывать непрерывную базу данных транзакций, не дожидаясь завершениями других баз данных. Эта версия параллельной копии, можно понять, как SQL базы данных потока.
MySQL 5.7 введена многопоточный механизм репликации подчиненного (далее МТС, ведомый многопоточной, также известный как параллельная копия параллельной репликации). Например, компания много раз поставщика электроэнергии бизнеса, после открытия параллельной репликации, задержка репликации снизилась с 8 часов до 0, чтобы решить непосредственную проблему латентности.
Тем не менее, группа МТС внедрить механизмы , основанные, в общем, на основном параллельного выполнения , как, о том , как играть с сервера . Здесь существует возможность того, что если главный сервер параллелизм недостаточных эффекты от параллельности машины будет значительно уменьшены.
Тем не менее, если первичный сервер однопоточный или небольшое количество параллельно выполняемых потоков, текущий МТС или будет механизм задержки. MySQL 8.0 базируется на последней writeset МТС является окончательным решением. Т.е. две сделки, до тех пор, как обновленная запись не перекрываются (Coverlap), то из машины могут быть выполнены параллельно без группы, даже если основной сервер один поток выполнения, по-прежнему можно воспроизводить с сервера параллельно. Я считаю, что это самый лучший путь для решения МТС окончательная форма
Резюме
MySQL 5.7 Enhanced представили многопоточных Раб для решения проблемы задержки одержимости MySQL репликации десятилетий длинных, напоминающий некоторые из незнания пользователя PostgreSQL снова, не опережать для MySQL впечатлению, не обязательно физическая репликация определенно лучше , чем логика копия имеет преимущество, в то время как MySQL МТС 5,7 был полностью решить проблему задержки.
Профиль открытые МТС:
# slave
slave-parallel-type=LOGICAL_CLOCK #基于组提交的并行复制方式
slave-parallel-workers=16 #并行复制测试 开启16个线程 效果最佳
master_info_repository=TABLE #开启MTS功能后，务必将参数master_info_repostitory设置为TABLE，这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升，资源的竞争也会变大。在之前 InnoSQL 的版本中，添加了参数来控制刷新master.info这个文件的频率，甚至可以不刷新这个文件。因为刷新这个文件是没有必要的，即根据master-info.log这个文件恢复本身就是不可靠的。在MySQL5.7中，推荐将master_info_repositor
y设置为TABLE，来减小这部分的开销
relay_log_info_repository=TABLE
relay_log_recovery=ON