Replicação de retardo mestre-escravo do MySQL

3

Nossa empresa está usando TokuDB na produção e estamos tendo muitos problemas tentando atenuar o atraso em nosso escravo. É muito estranho, porque estamos falando de poucas linhas ... mas com alguns dados fica defasada.

O escravo é um banco de dados somente leitura.

Para mais informações, estamos usando:

CPU : CPU Intel (R) Core (TM) i5-2400 a 3.10GHz (4 núcleos)

RAM : 16 GB

HDD : 2Tb ST2000DM001 (sistema de arquivos EXT4)

Aqui você pode ver algumas saídas de desempenho de E / S. Eu colo fora deste post, porque acho que dessa maneira será mais fácil para a leitura.

iostat -x 1 output, quando temos uma situação de atraso link

fio , para E / S de disco: link

Fizemos alguns ajustes no disco, extraídos do link do livro de Steven Corona:

  • Alterou o agendador de E / S para noop .
  • Desligou os tempos de acesso ao sistema de arquivos, noatime e nodiratime in /etc/fstab
  • Aumentou o número de arquivos abertos em /etc/security/limits.conf :
* soft  nofile  999999
* hard  nofile  999999

Alguns ajustes que fizemos na configuração:

MESTRE

# * 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

ESCRAVO

# * 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
    
por blacksoul 19.11.2012 / 11:45

1 resposta

1

Acho que isso já está resolvido, devido à ajuda do @ symcbean.

Eu desativei as barreiras, defina data = ordered, usei async e checksums. Finalmente, migramos para o MariaDB, mas ainda temos o TokuDB

Eu esqueci de mencionar que também definimos tokudb_cache_size = 8G , como o TokuDB recomenda, 50% da memória física

    
por 21.11.2012 / 15:53