web-dev-qa-db-ja.com

MySQLレプリケーションのパフォーマンス

2台のマシン間でのMySQL 5.5レプリケーションのパフォーマンスに重大な問題があります。ほとんどの場合、ステートメントベースのレプリケーションを持つmyISAMテーブルです。バイナリログとmysqlデータディレクトリは両方とも同じFusion ioDriveにあります。

この問題は最近、レプリケーションを約10分間停止する必要があったときに大きな問題でした。 3時間。他の負荷なしで再び追いつくのに約10時間かかりました。

10 hours to catch up

レプリケーションのパフォーマンスを向上させるにはどうすればよいですか？マシンBは、1つのmySQLスレッドのみがデータを書き込んでいたため、基本的にアイドル状態です（少し、IO、16のうちの2つの最大コア）。ここに私が持っていたいくつかのアイデアがあります：

  • 行ベースのレプリケーションに切り替えます。テストでは、これは10〜20％のパフォーマンス向上のみをもたらしました
  • マルチスレッドレプリケーションでmySQL 5.6にアップグレードします。データを個別のデータベースに簡単に分割することができ、ベンチマークはこれが役立つことを示しているようですが、コードは本番稼働の準備ができていないようです。
  • レプリケーションの高速化に役立ついくつかの構成変数

主な問題は 3時間の一時停止後に追いつくのに10時間かかる場合、これはレプリケーションが10時間で13時間のデータを書き込んでいること、またはデータの着信速度の130％で書き込むことができることを意味します近い将来、マスターマシンで少なくとも2倍の書き込みを行う予定なので、レプリケーションのパフォーマンスを向上させる方法が必要です。

マシンA：

  • 主人
  • 24 GBラム
  • 1.2TB Fusion ioDrive2
  • 2x E5620
  • ギガビット相互接続

my.cnf：

[mysqld]
server-id=71
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

log-bin=/data_fio/mysqlbinlog/mysql-bin.log
binlog-format=STATEMENT
replicate-ignore-db=mysql

log-slave-updates = true

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

マシンB：

  • Slave
  • 36 GB RAM
  • 1.2TB Fusion ioDrive2
  • 2x E5620
  • ギガビット相互接続

my.cnf：

[mysqld]
server-id=72
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

plugin-load=archive=ha_archive.so;blackhole=ha_blackhole.so

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock
mysqlperformancereplicationmyisam
15
Nick

うわー、あなたはこの問題のためにいくつかのひどく頑丈なハードウェアを持っています。 Btree検索などのパフォーマンスを20〜50％向上させるために、Sandy/Ivy Bridge CPUにアップグレードすることを除いて、ハードウェアの点でこれ以上投入することはできません。

私の強みはInnodbであることに注意してください。

  1. あなたが神秘であることを無視し、それが違いを生まないかのように行動します。
  2. この問題は、アップグレードするための十分な原動力であると想定します。はい、アップグレードです。

Innodbは、頻繁にアクセスされるこれらの行をバッファプールに格納することにより、そのすべてのメモリを最大限に活用するのに役立ちます。必要なだけ大きく（メモリの80％など）調整でき、空き容量を増やすためにディスクにプッシュする必要があるまで、新しい読み取り/書き込みがメモリに残ります。最新のアクセスデータ。メモリ内では、FusionIOよりも桁違いに高速です。

アダプティブハッシュ、自動INCロックメカニズムなど、環境に恩恵をもたらすInnodbの機能は他にもたくさんあります。しかし、あなたは私よりもあなたのデータをよく知っています。

Innodbの世界では、良い解決策はスレーブを最適化することです。マスターにあるスレーブのすべてのインデックスが本当に必要ですか？インデックスは、挿入/更新/削除のボールとチェーンであり、Fusion IOカードの場合、[〜＃〜] even [〜＃〜]です。ここではIOPSだけがすべてではありません。Sandy/ Ivyブリッジプロシージャは、メモリスループットとコンピューティングパフォーマンスがはるかに優れています。現在のWestmereに大きな違いをもたらすことができます（図20-50％全体）。削除スレーブで必要のないすべてのインデックス！

次に、ほぼ確実にinnodbのみに適用されます。mk-prefetchは、スレーブがそれらを書き込む前に、どの更新を認識できるかです。これにより、mk-prefetchが最初に読み取りクエリを実行できるようになり、単一のreplが書き込みクエリを実行するまでに、データがメモリに強制的に置かれます。これは、データがFusionIOではなくメモリ内にあることを意味します。これにより、[〜＃〜]巨大な[〜＃〜]の違いが生じます。多くの企業がこれを永続的なソリューションとして使用しています。詳細は Percona Toolkit をチェックしてください。

3番目に、そして最も重要なこととして、Innodbにアップグレードしたら、必ずTokutekをチェックアウトしてください。これらの人たちは、Innodbの書き込み/更新/削除のパフォーマンスをロングショットで超えている、ひどく素晴らしいものをいくつか持っています。彼らは主要な利点の1つとしてレプリケーション速度の向上を売り込んでおり、FusionsがIOPSをクレイジーIOPSにする理由をベンチマークから見ることができます Btreesの場合はまだ役に立ちません 。 （注：私が独自に検証したわけではありません。）それらはbtreeインデックスのドロップイン置換を使用しますが、これは明らかに複雑ですが、btreeインデックスのアルゴリズムの速度制限の多くを改善します。

トクテックの採用を検討中です。書き込み速度が大幅に向上した場合は、インデックスを追加できます。データとインデックスをこのようなすばらしい比率で圧縮するため（引用された25倍）、データの増加に対して（パフォーマンス、メンテナンス）価格を支払う必要さえありません。ただし、エンジンの料金（$）は、事前圧縮されたGB、IIRCあたり年間250ドルです。データを複製すると割引が適用されますが、スレーブにTokutekをインストールするだけで、マスターをそのまま維持することもできます。 MIT Algoritms Open Courseware講義 で技術的な詳細を確認してください。あるいは、彼らはブログにたくさんの技術的なものを持っています、そしてビデオを見るために1:20を持っていない人のための定期的なホワイトペーパー。このビデオは、読み取り速度を示すBig-Oの公式も示していると思います。私は読み取りが遅い（常にトレードオフがある！）と想定していますが、式は複雑すぎてどれほどかを測定できません。彼らはそれは大体同じであると主張します、しかし私はむしろ数学を理解したいと思います（そうではありません！）。あなたは私よりもこれを発見するより良い状況にあるかもしれません。

追伸私はTokutekとは関係がありません。私は彼らの製品を実行したことがなく、彼らが私がそれらを見ているかどうかさえ知りません。

更新：

このページで他にいくつか質問があるので、私は次の質問に答えると思います。

まず、例外的な環境がない限り、スレーブプリフェッチはほぼ間違いなくmyisamに対して機能しません。これは主に、プリフェッチが書き込みを行うテーブルそのものをロックするか、スレーブスレッドがプリフェッチデーモンに必要なテーブルをロックしているためです。レプリケーションのためにテーブルのバランスが非常によく取れており、さまざまなテーブルがラウンドロビン方式で書き込まれている場合、これは機能する可能性がありますが、これは非常に理論的なことです。本「High Performance Mysql」の「Replication Problems」セクションに詳細情報があります。

第2に、おそらくあなたのスレーブは1.0-1.5の負荷を保持していますが、他のprocまたはクエリを実行しているが、ベースラインが1.0の場合、それよりも高くなる可能性があります。これは、CPUバウンドである可能性が高く、FusionIOがオンボードである可能性が高いことを意味します。先に述べたように、Sandy/Ivy Bridgeは少し活気を与えますが、おそらくラグを最小限に抑えてラフな時間を乗り越えるには十分ではありません。このスレーブの負荷がほとんど書き込み専用の場合（つまり、読み取りが多くない場合）、CPUはほぼ確実にbtree挿入/削除の位置の計算に時間を費やしています。これにより、重要でないインデックスの削除に関する上記のポイントが強化されます。後でいつでも追加できます。ハイパースレッディングを無効にしても機能しません。CPUの増加は敵ではありません。 32GBのRAM（64GBなど）を超えると、 RAMディストリビューション について心配する必要がありますが、それでも症状は異なります。

最後に、そして最も重要なことは（この部分はスキップしないでください））、RBR（行ベースのレプリケーション）を実行していることを前提としています。ただし、ここではさらにmoreパフォーマンスを得る方法があるかもしれません。 Mysqlバグ53375 主キーなしでレプリケートされるテーブルがある場合に発生する可能性があります。スレーブは基本的に、主キー以外を使用するほどスマートではないため、1つが存在しないと、レプリケーションスレッドは更新ごとにフルテーブルスキャンを強制的に実行します。修正は、良性のサロゲート自動インクリメント主キーを追加することです。これができるのは、テーブルが大きい場合のみです（たとえば、数万行以上）。もちろん、これにはテーブルに別のインデックスがあり、CPUで支払う価格が高くなるという犠牲が伴います。 InnoDBが1つ追加しない場合は裏で追加するため、これに対する理論的な議論はほとんどありません。ただし、幻影の1つは53375に対する有効な防御策ではありません。タングステンもこの問題を克服できますが、タングステンを使用するときは必要です。エンコーディングをまっすぐにします。最後にそれを使って遊んだとき、UTF8以外の文字列を複製する必要があると、ひどく死んでしまいます。それは私がそれをあきらめた頃です。

4
fimbulvetr

答えではありませんが、柔軟性を高めるために タングステンレプリケーター とその商用製品を検討してください。ボトルネックとなっているのは、シングルコアでのCPU使用率が100％ですか？

4
pQd

したがって、スレーブでバックアップを実行していて、myiasmテーブルを使用している場合、破損を防ぐためにバックアップを実行するためにテーブルをロックしています。そのため、レプリケーションは、バックアップが完了するまで機能しません。その後、追いつきます。

2
Mike