web-dev-qa-db-ja.com

Galeraマルチマスターで100倍の挿入パフォーマンス

多くの行を挿入するアプリケーションを実行していますが、パフォーマンスが低下していました。そこで、sysbenchとoltp_insert.luaを使用してGalera Clusterのベンチマークを開始しました（実際にはランダムキーで挿入します）。

クラスターのパフォーマンスは本当に悪いです。

同じテストで：

  • スタンドアロンのDB iとして、約35000 tpsを実行できます。
  • Galeraマルチマスターでのパフォーマンスは350 tps

テーブル構造は次のとおりです。

       Table: sbtest1
Create Table: CREATE TABLE `sbtest1` (
  `id` int(11) NOT NULL,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

私がこれまでに試したこと（成功なし）：

  • 増加する wsrep_slave_threads=16
  • 使用するクライアントスレッドの数に関係なく、TPSは350のままです（トランザクションがDBによって何らかの方法でシリアル化されているように見えます）
  • セットする wsrep_sync_wait=0（読み取りは実行しませんが）
  • dbはbinlogを使用せず、有効になっていません。

構成：

[mysqld]   
binlog_format=ROW   
innodb_autoinc_lock_mode=2    
bind-address=0.0.0.0   
datadir=/var/lib/mysql

innodb_buffer_pool_size = 300MB
innodb_large_prefix=1
innodb_file_format=Barracuda

transaction-isolation = READ-COMMITTED

wsrep_on=ON  
wsrep_provider=/usr/lib64/galera/libgalera_smm.so           
wsrep_slave_threads = 16         
wsrep_max_ws_rows=131072    
wsrep_max_ws_size=1073741824    
wsrep_convert_LOCK_to_trx=0    
wsrep_causal_reads=OFF
wsrep_sst_method=xtrabackup-v2
mysqlgalera
3
mhstnsc

同じ問題が発生しました。最初に行うことは、次の変数を確認することです。

select @@innodb_flush_log_at_trx_commit;

select @@sync_binlog;

Innodb_flush_log_at_trx_commitを2に設定し、sync_binlogを0に設定すると、パフォーマンスが劇的に向上します。

その理由は、認証メカニズムとマルチマスター動作の性質にあります。トランザクションクラスタをコミットするために、すべてのノードでコミット時にすべてのログが確実にフラッシュされるため、挿入は非常に遅くなります。

キャッシュがRAM以下のクエリにも当てはまることを確認してください：

select ((@@thread_stack +@@binlog_cache_size +@@read_buffer_size + @@read_rnd_buffer_size +@@sort_buffer_size +@@join_buffer_size + @@global.net_buffer_length +@@global.query_prealloc_size + @@binlog_stmt_cache_size) * @@max_connections + (@@query_cache_size + @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size))/(1024*1024);
2
Ilshat Karazbayev

Galeraはマルチマスターで正しく動作しますが、それでもコミット時の「認証」はすべての競合をチェックする必要があることを意味します。複数のノードで同じテーブルにレコードを挿入すると、そのような競合が発生する可能性が高くなります。すべての犠牲トランザクションはロールバックされ、アプリケーションは最初からそれらを繰り返す必要があります。

単一のアプリケーションの場合、ほとんどの場合、マルチマスター操作は間違ったセットアップです。シングルマスターで実行し、すべてのクライアントが同じデータベースサーバーノードにアクセスできるようにします。

それでも、認証プロセスにより、Galeraのセットアップはスタンドアロンノードよりも少し遅くなりますが、100倍にはなりません。

1
Jörg Brühe

Galeraは、クラスターに対する読み取り/書き込み比率が同じになるように設計されているため、読み取り/書き込みテストの数が多いほど良いでしょう。また、sysbenchはおそらくクラスターの1つのノードのみを攻撃しています。おそらく、予想される使用法に近いテストを設計します。

一括挿入/変更の場合、Galeraには低いフロー制御制限があり、それを増やすことができます。 SHOW GLOBAL STATUS LIKE 'wsrep%'は、この制限または別の制限に達しているかどうかを示します。

リンクごとに wsrep_provider_options の使用可能なオプション。

考慮すべきその他のオプション：

  • gcs.fc_master_slave
  • gcs.recv_q_hard_limit
1
danblack