Проблемы, решаемые репликацией master-slave
- Распределение данных: распределяйте данные по разным географическим местоположениям посредством репликации.
- Балансировка нагрузки: разделение чтения и записи и загрузка чтения в несколько подчиненных библиотек
- Резервное копирование: доступно как резервное копирование в реальном времени.
- Высокая доступность: Высокая доступность с первичной первичной репликацией
принцип репликации
Принцип репликации на самом деле очень прост и делится только на следующие три шага:
-
Изменения данных записываются в двоичный журнал основной базы данных. В частности, прежде чем каждая транзакция будет готова к отправке для завершения обновления данных, основная база данных записывает событие обновления данных в двоичный журнал, и Mysql будет следовать порядку транзакции. отправка, запись бинарного лога. После завершения регистрации основная библиотека уведомляет механизм хранения о необходимости фиксации транзакции.
-
Ведомая библиотека запустит поток ввода-вывода, который подключится к главной библиотеке. Поток дампа binlog в основной библиотеке будет читать события обновления в локальном файле журнала binlog в основной библиотеке. Он отправляется в подчиненную библиотеку, и после получения лога из библиотеки он будет записан в локальный релейный лог relay-log.
-
События в журнале ретрансляции relay-log считываются из потока SQL в подчиненной библиотеке и воспроизводятся в подчиненной библиотеке. (До версии 5.6 поток SQL был однопоточным, что увеличивало задержку между ведущим и подчиненным)
Промежуток времени
Что записывает файл журнала, в конце концов, что это такое? mysql поддерживает два формата журналов, оба формата журнала также отражают собственную репликацию.
Репликация на основе операторов:
Репликация на основе операторов эквивалентна логической репликации, то есть двоичный журнал записывает рабочие операторы, а репликация достигается путем воспроизведения этих операторов в ведомой библиотеке. Этот метод прост, двоичный журнал занимает меньше места, а эффективность передачи высока при небольшой пропускной способности. Однако обновления на основе операторов зависят от других факторов.Например, при вставке данных использование функции метки времени для вызова текущего времени в качестве значения времени также вызовет проблемы, поскольку значение времени несовместимо из-за задержки между мастером и раб. Проблемы также могут возникнуть с хранимыми процедурами и триггерами. Поэтому в разработке мы должны максимально укладывать логику в слой кода, а не в mysql, который непросто расширить.
Копирование на основе строк:
Репликация на основе строк эквивалентна физической репликации, т. е. двоичный журнал записывает каждую строку данных, которая была фактически обновлена. Это приводит к относительно высокой нагрузке на репликацию строк, поскольку журнал занимает много места, а передача занимает большую полосу пропускания. Однако она более точна, чем репликация на основе операторов, и может маскировать некоторые несоответствия, вызванные различиями между главной и подчиненной библиотеками. Например, только что упомянутая функция метки времени.
Сравните два:
-
Репликация заявления:
- Высокая эффективность передачи и уменьшенная задержка.
- Присвоение оператора не завершается ошибкой при обновлении несуществующей записи из библиотеки. Репликация строк, с другой стороны, приводит к сбоям, что может привести к более раннему обнаружению несоответствий между ведущим и подчиненным.
- Предположим, что в таблице один миллион фрагментов данных, один SQL обновляет все таблицы, репликация на основе операторов должна отправить только один SQL, а репликация на основе строк должна отправить один миллион записей обновления.
-
Копия строки:
- Нет необходимости выполнять план запроса.
- Я не знаю, какое выражение выполняется.
- Например, оператор для обновления общего количества баллов пользователя должен подсчитать все баллы пользователя и записать их в пользовательскую таблицу. Если он основан на репликации операторов, ведомой библиотеке необходимо снова подсчитать баллы пользователя, но на основе репликации строк запись обновляется напрямую, и нет необходимости подсчитывать баллы пользователя.
Поскольку оба метода имеют свои преимущества и недостатки, mysql динамически переключается между этими двумя режимами репликации. По умолчанию используется заявление.
Точки конфигурации
# 如果在双主复制结构中没有设置ID的话就会导致循环同步问题
server_id=1
# 即日志中记录的是语句还是行更新或者是混合
binlog_format=mixed
# 在进行n次事务提交以后，Mysql将执行一次fsync的磁盘同步指令。将缓冲区数据刷新到磁盘。
# 为0的话由Mysql自己控制频率。
sync_binlog=n
# 为0的话，log buffer将每秒一次地写入log file中并且刷新到磁盘。
# mysqld进程崩溃会丢失一秒内的所有事务。
# 为1的话，每次事务log buffer会写入log file并刷新到磁盘。（较为安全）
# 在崩溃的时候,仅会丢失一个事务。
# 为2的话，每次事务log buffer会写入log file，但一秒一次刷新到磁盘
innodb_flush_logs_at_trx_commit=0
# 阻止从库崩溃后自动启动复制，给一些时间来修复可能的问题，
# 崩溃后再自动复制可能会导致更多的问题。并且本身就是不一致的
skip_slave_start=1
# 是否将从库同步的事件也记录到从库自身的bin-log中
# 允许备库将重放的事件也记录到自身的二进制日志中去，可以将备库当做另外一台主库的从库
log_slave_update
# 日志过期删除时间，延迟严重的话会导致日志文件占用磁盘
expire_logs_days=7
Три параметра innodb_flush_logs_at_trx_commit легко спутать. Ниже приводится подробный анализ:
MySQL сначала записывает журнал в буфер журнала, а затем записывает данные из буфера журнала в файл журнала.В это время файл журнала в памяти записывается, и операционной системе все еще нужно записать данные в памяти сбросить на диск.
- Параметр 0: MySQL записывает данные буфера журнала в файл журнала и сбрасывает их на диск каждую секунду. Это означает, что при сбое mysql все транзакции в течение секунды будут потеряны.
- Параметр 1: Каждая фиксация транзакции будет записывать буфер журнала в файл журнала и сбрасывать его на диск. Это означает, что при сбое mysql будет потеряна только одна транзакция.
- Параметр 2: Каждая фиксация транзакции будет одновременно записывать буфер журнала в файл журнала, но не на диск. MySQL будет контролировать, чтобы файл журнала сбрасывался на диск каждую секунду. При сбое MySQL операционная система не выходит из строя. ., в log_file будет потеряна только одна транзакция, операционная система по-прежнему будет сбрасывать файл журнала на диск, и если операционная система также выйдет из строя или потеряет питание, транзакции в течение секунды будут потеряны.
Рекомендуемое использование: innodb_flush_logs_at_trx_commit=2 и sync_binlog=500 будут работать быстрее. Если innodb_flush_logs_at_trx_commit и sync_binlog равны 1, это безопаснее.
проблема с задержкой
Генерация задержки:
- Когда параллелизм TPS основной библиотеки высок, поскольку основная библиотека записывается несколькими потоками, а поток SQL подчиненной библиотеки является однопоточным, SQL подчиненной библиотеки может не поспевать за скоростью обработки основная библиотека (производитель работает эффективнее, чем потребитель быстрее, что приводит к накоплению товаров).
Замедленное разрешение:
Сеть: распространяйте подчиненную библиотеку в той же локальной сети или в среде с меньшей сетевой задержкой.
Оборудование: настройте лучшее оборудование из библиотеки, чтобы улучшить производительность произвольной записи.
Конфигурация: настройте sync_binlog=0, innodb_flush_log_at_trx_commit=2, logs-slave-updates=0 из библиотеки, увеличьте размер innodb_buffer_pool_size, разрешите выполнение большего количества операций в памяти Mysql и сократите дисковые операции. Или обновите версию Mysql5.7, чтобы использовать параллельную репликацию.
Архитектура: например, попробуйте читать и писать в основную библиотеку во время транзакций, а также читать и писать в других не-транзакциях из подчиненной библиотеки. Устранение несоответствий базы данных, вызванных некоторыми задержками. Увеличьте кеш, чтобы уменьшить нагрузку на некоторые подчиненные библиотеки.