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

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

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

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

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

主な問題は、3時間休止した後、10時間かかると、レプリケーションは10時間で13時間のデータを書き込むか、または入ってくるデータの速度の130％で書き込むことができることを意味します。近い将来、マスターマシンで少なくとも2回の書き込みが行われるため、レプリケーションパフォーマンスを改善する方法が切実に必要です。

マシンA：

• 主人
• 24GBラム
• 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：

• 奴隷
• 36GBラム
• 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

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

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

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

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

アダプティブハッシュ、自動incロックメカニズムなど、環境にとって有益なInnodb機能がさらに多くあります。ただし、データは私よりもよく知っています。

innodbの世界では、適切な短期的な解決策はスレーブを最適化することです。マスター上にあるスレーブ上のすべてのインデックスが本当に必要ですか？インデックスは、挿入/更新/削除のボールチェーンですEVEN融合IOカードで。IOPSはすべてではありません。Sandy / Ivyブリッジprocは、メモリスループットとコンピューティングパフォーマンスがはるかに優れています。これにより、現在のWestmereに大きな違いをもたらすことができます。（図20-50％全体）。スレーブ上で不要なインデックスをすべて削除してください！

第二に、ほぼ確実にinnodbのみに適用されるのは、mk-prefetchがどの更新をスレーブが書き込む前に知ることができるということです。これにより、mk-prefetchが最初に読み取りクエリを実行できるようになります。これにより、単一のreplが書き込みクエリを実行するまでにデータを強制的にメモリに格納できます。これは、データがFusionIOではなくメモリにあることを意味し、パフォーマンスが大幅に向上します。これにより、大きな違いが生まれます。多くの企業がこれを永続的なソリューションとして使用しています。詳細については、Percona Toolkitをご覧ください。

第三に、そして最も重要なことは、Innodbにアップグレードしたら、必ずTokutekをチェックアウトすることです。これらの人たちは、Innodbの書き込み/更新/削除のパフォーマンスをロングショットで上回る、驚くほど素晴らしいものをいくつか持っています。主な利点の1つとしてレプリケーション速度の向上を宣伝しており、ベンチマークから、Btreesの場合に FusionsのクレイジーなIOPSがまだ役に立たないことがわかります。（注：私が独自に検証したわけではありません。）btreeインデックスのドロップイン置換を使用します。

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

Ps私はTokutekと提携していない、私は彼らの製品を実行したことがなく、彼らは私がそれらを見ていることすら知らない。

更新：

このページには他にも質問がありますが、私は次のように考えました。

まず、例外的な環境がない限り、myisamではスレーブプリフェッチはほぼ確実に機能しません。これは主に、プリフェッチによって書き込みたいテーブルがロックされるか、プリフェッチデーモンが必要とするテーブルがスレーブスレッドによってロックされるためです。テーブルのレプリケーションのバランスが非常によく、異なるテーブルがラウンドロビン方式で書き込まれている場合、これは機能する可能性がありますが、これは非常に理論的であることに注意してください。本「High Performance Mysql」の「レプリケーションの問題」セクションに詳細があります。

第二に、おそらくあなたのスレーブは1.0-1.5の負荷を保持しています。他のprocやクエリを実行しているがベースラインが1.0の場合、それはより高いかもしれません。これは、CPUに縛られている可能性が高いことを意味します。これは、FusionIOが搭載されている可能性が高いことです。前述したように、Sandy / Ivy Bridgeはもう少し威力を発揮しますが、ラグを最小限に抑えて荒れた時間を乗り切るにはおそらく十分ではありません。このスレーブの負荷がほとんど書き込み専用である場合（つまり、読み取り回数が少ない場合）、CPUはほぼ確実にbtreeの挿入/削除の位置の計算に時間を費やしています。これにより、重要ではないインデックスの削除に関する上記の私のポイントが強化されます-いつでもいつでも追加できます。ハイパースレッディングを無効にしても機能しません。CPUを増やすことは敵ではありません。32GBのRAM、たとえば64GBを超えると、RAMの分配について心配する必要があります、それでも症状は異なります。

最後に、そして最も重要なことは（この部分をスキップしないでください;））、今度はRBR（行ベースのレプリケーション）を実行していると仮定しています。ただし、ここでさらにパフォーマンスを向上させる方法があるかもしれません。主キーなしでレプリケートされるテーブルがある場合、MySQLバグ53375が顕在化する可能性があります。スレーブは基本的に主キー以外のものを使用するほどスマートではないため、スレーブが存在しないため、レプリケーションスレッドは更新ごとに全テーブルスキャンを強制的に実行します。。修正は、良性で代理の自動増分主キーを追加するだけです。これは、テーブルが大きい場合（数万行以上の場合）にのみ行います。もちろん、これにはテーブルに別のインデックスを作成するコストがかかり、CPUで支払う価格が上がります。InnoDBが裏で追加しないので、これに対する理論的な議論はほとんどないことに注意してください。ファントム1は、しかし、53375.に対して有用防衛ではないタングステンは、あまりにもこの問題を克服することができますが、必要なタングステンを使用しているときにあなたのストレートエンコードしていることを確認します。前回使ったとき、UTF8以外の文字列を複製する必要があると恐ろしく死にました。それは私がそれをあきらめた時間についてです。

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

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