Назад | Перейти на главную страницу

Репликация задержки ведущего и ведомого в MySQL

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

Slave - это БД, доступная только для чтения.

Для получения дополнительной информации мы используем:

ЦПУ: Intel (R) Core (TM) i5-2400 CPU @ 3,10 ГГц (4 ядра)

ОЗУ: 16 Гб

HDD: 2 ТБ ST2000DM001 (файловая система EXT4)

Здесь вы можете увидеть некоторые результаты производительности ввода / вывода. Я вставляю его вне этого поста, потому что думаю, так будет легче читать.

iostat -x 1 вывод, когда у нас есть лаговая ситуация http://paste.laravel.com/bjv

fio, для дискового ввода-вывода: http://paste.laravel.com/bjG

Мы сделали несколько настроек диска, взятых из книги Стивена Корона. http://www.scalingphpbook.com:

* soft  nofile  999999
* hard  nofile  999999

Некоторые настройки, которые мы внесли в конфигурацию:

МАСТЕР

# * Query Cache Configuration
query_cache_limit               = 0
query_cache_size                = 0
query_cache_type                = 0
innodb_file_per_table           = 1

innodb_file_format              = barracuda
innodb_flush_method             = O_DIRECT
innodb_flush_log_at_trx_commit  = 1
innodb_log_file_size            = 128M

innodb_buffer_pool_size         = 13500M
innodb_read_io_threads          = 16
innodb_write_io_threads         = 16
innodb_io_capacity              = 180
innodb_thread_concurrency       = 4

РАБ

# * Query Cache Configuration
query_cache_limit               = 0
query_cache_size                = 0
query_cache_type                = 0
innodb_file_per_table           = 1

innodb_file_format              = barracuda
innodb_flush_method             = O_DIRECT
innodb_flush_log_at_trx_commit  = 2
sync_binlog                     = 1

innodb_log_file_size            = 128M
innodb_buffer_pool_size         = 13500M
innodb_read_io_threads          = 16
innodb_write_io_threads         = 16

innodb_io_capacity              = 180
innodb_thread_concurrency       = 4

Я думаю, что это уже решено благодаря помощи @ symcbean.

Я отключил барьеры, установил данные = заказанный, использовал асинхронную фиксацию и контрольные суммы. Наконец, мы перешли на MariaDB, но у нас все еще есть TokuDB.

Я забыл упомянуть, что мы также устанавливаем tokudb_cache_size = 8G, как рекомендует TokuDB, 50% физической памяти