☰

Проблемы с репликацией MySQL. Почему binlogs растет так быстро?

tag-icon • tag-icon mysql docker replication
Проблемы с репликацией MySQL. Почему binlogs растет так быстро?

У меня есть 2 сервера MySQL:
Главный сервер: mysql версии 5.7.14
Подчиненный сервер: mysql версии 5.7.14 в контейнере Docker (с официального docker hub).
GTID-репликация.

У меня две проблемы:

  1. Бинлоги растут очень быстро. Я установил ограничение на ротацию в 2 дня, но это не помогает - каждый день папка бинлогов увеличивается как минимум в два раза (первый день 25 Гб, второй 50, третий 80 и т. д.).
  2. Увеличивается количество секунд, на которое подчиненный сервер отстает от главного.

Сервера в локальной сети (100 мбит/с), SSD диски, размер базы данных около 40 Гб.
Клонирую базу данных для подчиненного сервера с помощью Percona Xtrabackup.

Может быть, конфигурация серверов неверна и мне нужно что-то исправить?

Это файл Master my.cnf:

[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

[mysqld_safe]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
explicit_defaults_for_timestamp

max_allowed_packet = 256M

log-error       = /var/log/mysql/error.log

symbolic-links=0

!includedir /etc/mysql/conf.d/

innodb_buffer_pool_size=15000M
innodb_buffer_pool_instances=1
sql_mode = ''

slow_query_log = 1
slow_query_log_file     = '/var/log/mysql/slow.log'
long_query_time = 1
log_queries_not_using_indexes = 0

#skip-grant-tables

default_week_format = 1

skip-name-resolve
sort_buffer_size=4M
join_buffer_size=4M
innodb_sort_buffer_size=4M
tmp_table_size=5000M
max_heap_table_size=5000M

[mysqld]
server-id = 1
binlog-format = row
gtid_mode=ON
enforce-gtid-consistency=ON
log-slave-updates
log_bin = /var/log/mysql/mysql-bin.log
performance_schema_max_digest_length = 8192
max_digest_length = 8192
max_binlog_size= 1G
expire_logs_days = 2
binlog-ignore-db=check_passport
replicate-ignore-db=check_passport

sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

key_buffer_size             = 16M
innodb_flush_method         = O_DIRECT
max_connections             = 200

#innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:5G

Это мой.cnf подчиненного сервера

[client]
port                        = 3306
socket                      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket                      = /var/run/mysqld/mysqld.sock
nice                        = 0

[mysqld]
sql_mode                    = ""
character_set_server        = utf8
collation_server            = utf8_general_ci
user                        = mysql
pid-file                    = /var/run/mysqld/mysqld.pid
socket                      = /var/run/mysqld/mysqld.sock
port                        = 3306
basedir                     = /usr
datadir                     = /var/lib/mysql
tmpdir                      = /tmp
language                    = /usr/share/mysql/english
old_passwords               = 0
bind-address                = 127.0.0.1
skip-host-cache
skip-name-resolve

skip-external-locking

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

max_allowed_packet          = 256M
#key_buffer_size             = 16M
innodb_buffer_pool_size     = 2048M
innodb_log_file_size        = 256M
innodb_file_per_table       = 1
innodb_flush_method         = O_DIRECT
innodb_flush_log_at_trx_commit  = 1

max_connections             = 136

query_cache_size            = 0

slow_query_log              = /var/log/mysql/mysql-slow.log
long_query_time             = 1

expire_logs_days            = 2
max_binlog_size             = 1G

[mysqldump]
quick
quote-names
max_allowed_packet          = 16M


[mysqld]
server-id = 2
binlog-format = row
gtid_mode=ON
enforce-gtid-consistency=ON

relay-log = /var/log/mysql/mysql-relay-bin.log

log_bin = /var/log/mysql/mysql-bin.log

skip_slave_start

log_slave_updates = 0
read_only = ON

innodb_file_per_table = ON
#innodb_buffer_pool_size = 3G
innodb_flush_method         = O_DIRECT
innodb_flush_log_at_trx_commit  = 1

max_binlog_size = 1G

#max_relay_log_size = 1G
#relay_log_space_limit = 20G
relay_log_recovery = ON

expire_logs_days = 2

#slave-parallel-workers = 0

binlog-ignore-db=check_passport
replicate-ignore-db=check_passport

replicate-ignore-table=gfk.application_insurance
replicate-ignore-table=gfk.archive_client_building
replicate-ignore-table=gfk.comments_passwords
replicate-ignore-table=gfk.date_interval

ВыходПОКАЗАТЬ СТАТУС ПОДЧИНЕННОГО УСТРОЙСТВА\G

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.4
                  Master_User: slave_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.004720
          Read_Master_Log_Pos: 518759418
               Relay_Log_File: mysql-relay-bin.000188
                Relay_Log_Pos: 213202356
        Relay_Master_Log_File: mysql-bin.004703
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: check_passport
           Replicate_Do_Table: 
       Replicate_Ignore_Table: gfk.application_insurance,gfk.date_interval,gfk.archive_client_building,gfk.comments_passwords
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 213202143
              Relay_Log_Space: 18773097825
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: Yes
           Master_SSL_CA_File: /var/lib/master_cert/ca.pem
           Master_SSL_CA_Path: 
              Master_SSL_Cert: /var/lib/master_cert/client-cert.pem
            Master_SSL_Cipher: 
               Master_SSL_Key: /var/lib/master_cert/client-key.pem
        Seconds_Behind_Master: 14488
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: 8ab33cfb-bb00-11e6-84cd-fa163eb352dd
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 8ab33cfb-bb00-11e6-84cd-fa163eb352dd:62276836-70424802
            Executed_Gtid_Set: 8ab33cfb-bb00-11e6-84cd-fa163eb352dd:1-67413143
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version:

решение1

Практично ли иметь Primary binlog_ignore = check_passport? Если да, и если в этой базе данных много трафика, то это «значительно» сократит бинлоги.

Большие DELETEsили UPDATEsзанимают много места в бинарном журнале, из-за чего бинарный журнал становится огромным. (Пример: обновление каждой строки таблицы из миллиона строк.) Укажите подробности; могут быть существенные обходные пути.

Сколько потоков реплики запущено на Replica? Это влияет на Seconds_behind_master. (Больше потоков, до некоторого предела, вероятно, уменьшится "за".)

innodb_flush_log_at_trx_commit = 1--> изменить на 2. Это снижает некоторую надежность (при сбоях), но повышает пропускную способность.

Сколько ОЗУ в каждом? Я вижу больший buffer_pool в Primary. ОбычноReplica должна быть более мощной машиной.

100 Мбит/с кажется мало; можете проверить, не заполнен ли он?

Свежие данные ежедневно

Вот эффективный способ заменывседанные в таблице:

  1. CREATE TABLE new LIKE real;
  2. LOAD DATA INFILE INTO new ... -- или что угодно
  3. `ПЕРЕИМЕНОВАТЬ ТАБЛИЦУ real В old, new В REAL;
  4. DROP TABLE old;

Шаг №2 — самая медленная часть.
Шаг №3 очень быстрый; это единственный раз, когда ваша таблица недоступна.
Никаких бинлог-интенсивов UPDATEили DELETE.

решение2

Я нашел решение для своего случая

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

SELECT t.table_schema,t.table_name,engine
FROM information_schema.tables t
INNER JOIN information_schema .columns c
on t.table_schema=c.table_schema
and t.table_name=c.table_name
and t.table_schema not in ('performance_schema','information_schema','mysql')
GROUP BY t.table_schema,t.table_name
HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

Затем:

  1. Скорость моей сети уже 1Гбит/с, там все ок.
  2. Я исключаю из репликации и регистрации базу данных, которая пересоздается каждый день.
  3. Увеличиваю на подчиненном ОЗУ до 23Гб (как на главном)
  4. Я переношу бинлоги на подчиненном устройстве с SSD на HDD - все в порядке - скорости HDD достаточно.
  5. Я установил log_slave_updates = 1, поскольку моя схема репликации — master>slave>slave.

И эти шаги решают мои проблемы! На данный момент мои бинлоги не превышают 10 Гб.

Связанный контент