しかし、Percona XtraDBクラスターのベースとなるGalera Clusterと呼ばれる代替ソリューションがあり、Ubuntuに関連するインストール、構成、およびテストについて説明します。
NDBclusterが優れているのはなぜですか？
最初：制限が少ない（NDBcluster制限のリスト：dev.mysql.com/doc/refman/5.5/en/mysql-cluster-limitations.html、XtraDB Cluster制限のリスト： www.percona.com/doc/percona-xtradb -cluster / restriction.html ）。
InnoDBのいくつかのMyISAMテーブルをやり直すだけで済みました。
第二に：Perkonaコードエンジンの複数のMySQLパッチ。
第三に、2つの単一の構成で動作する機能（これはテストにのみ適していることをすぐに予約します）。
そして最後に、MySQLフォークは現在傾向にあります:)
MySQLのフォークにねじ込まれたGalera Clusterよりも優れているものは何ですか？
すぐにバックアップを作成できるxtrabackupユーティリティの存在。 これは、新しいノードをクラスターに接続するときに、作業中のノードを停止してデータベースをそこから排出する必要がないため便利です。
設置
通常のUbuntuでのインストールは基本です。
gpg --keyserver hkp://keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A gpg -a --export CD2EFD2A | sudo apt-key add - sudo apt-get update sudo apt-get install percona-xtradb-cluster-server-5.5
時々、彼は解決できない依存関係を誓います。 その後、最初に依存関係をインストールし、次にサーバー自体をインストールするだけで十分です。
最初に、設定を何も変更せずに、mysqlコンソールに移動し（最初に起動するノードで十分）、バックアップ用のユーザーを追加する必要があります。
grant RELOAD, LOCK TABLES, REPLICATION CLIENT, FILE on *.* to backup@localhost identified by 'password';
次に、1つの小さな手直しが必要です。 実際のところ、Ubuntでは、shとのシンボリックリンクがダッシュにつながり、クラスター起動スクリプトはbash用に設計されています。 禁忌がない場合は、このシステム全体で解決できます。
dpkg-reconfigure dash
いいえと答えます
クラスターを起動した後のデータベースは完全に同一になるため、すべてのノードのシステムユーザーのパスワードは最初のようになります。 したがって、最初に起動するサーバーから/etc/mysql/debian.cnfファイルを他のサーバーにコピーする必要があります。
私の設定は次のようになります。
[mysqld_safe] wsrep_urls=gcomm://192.168.1.1:3400,gcomm://192.168.1.2:3400,gcomm:// [mysqld] port=3306 socket=/var/run/mysqld/mysqld.sock datadir=/var/lib/mysql basedir=/usr user=mysql log_error=error.log binlog_format=ROW wsrep_provider=/usr/lib/libgalera_smm.so wsrep_sst_receive_address=192.168.1.1:3500 wsrep_node_incoming_address=192.168.1.1 wsrep_slave_threads=2 wsrep_cluster_name=cluster0 wsrep_provider_options="gmcast.listen_addr=tcp://192.168.1.1:3400;" wsrep_sst_method=xtrabackup wsrep_sst_auth=backup:password wsrep_node_name=node0 innodb_locks_unsafe_for_binlog=1 innodb_autoinc_lock_mode=2 innodb_buffer_pool_size=5000M innodb_log_file_size=256M innodb_log_buffer_size=4M [client] port=3306 socket=/var/run/mysqld/mysqld.sock
libgalera_smm.soの場所を確認します。
wsrep_slave_threadsパラメーターの値は、コア数* 4として設定することをお勧めします。
wsrep_sst_authでは、バックアップのユーザー名とパスワードが指定されます。
innodb_buffer_pool_size、innodb_log_file_size、innodb_log_buffer_size-パフォーマンスに影響し、実験的に選択されます。 私の場合、各ノードのRAMは8ギガです。
ノードを追加するには、それらをwsrep_urls行に追加します（行の最後に空のエントリがあるはずです）。
ファイルで見つかったすべてのIPアドレス（wsrep_urls行を除く）は、現在のノードのアドレスを示します。 このファイルを他のノードに配布するときは、変更する必要があります。 また、wsrep_node_nameでノードの名前を変更する必要があります。
私の設定では、ポート3400が同期に使用され、ポート3500がダンプを埋めるために使用され、ポート3306（標準）がクライアントの接続に使用されます。
同じマシンで複数のノードを実行し、それらに異なるポートを割り当てることができます。 これを行う場合は、/ etc / mysqlにいくつかの構成ファイルを作成し、たとえば次のコマンドでサーバーを起動する必要があります。
/usr/bin/mysqld_safe --defaults-file=/etc/mysql/my0.cnf
xtrabackupは、標準ソケット/var/run/mysqld/mysqld.sockを使用してのみ接続できることに注意してください（構成のパラメーターは無視されます）。 したがって、この場合は使用しないでください：wsrep_sst_method = rsync
結論として、デーモンを再起動します。
sudo service mysql restart
問題が発生した場合は、/ var / lib / mysql / error.logをご覧ください。
通常、構成内のログのサイズが変更されるため、/ var / lib / mysql / ib_logfile *を削除する必要があります。
/ var / lib / mysql /全体を消去して（データベースに価値がない場合）、デフォルトのデータベースを再作成する方が簡単な場合があります。
mysql_install_db
記事の最後に引用した他の考えられるエラー。
ノード数
メーカーは少なくとも3つを推奨していますが、NDBとは異なります。最初は、すべてのノードは同じランクであり、同じ機能を備えています。 2つのノードを作成することを妨げるものは何もありません。
2日間の構成では、すべてがシンプルで悲しいです。ノード間の接続がなくなるまで機能します。 この場合、スプリットブレインから保護するために、クラスターは何も実行できません。 構成にはいくつかのオプションがあり、接続が切断されても機能しますが、もちろん、それらからの損害は十分です-接続が表示されると、データベースの2つの異なるコピーを取得します。
私の場合、3つのノードを持つオプションは適合しませんでした。コロケーションにサーバーが2つしかないためです。また、オフィスチャネルのどこかに3つ目のサーバーを追加すると、クラスターの動作速度が最も遅いノードの速度によって決定されるため、パフォーマンスが大きく損なわれます。
しかし、解決策があります：Galera Arbitator。 これは、データベースを保存しない欠陥ノードであり、高速チャネルを必要としませんが、現時点ではノードはノードと連絡を取り合い、機能し続けます。 このノードは非常に欠陥があるため、構成を使用することすらできません。すべてのパラメーターはコマンドラインを介して渡されます。
パラメーターのうち、通常ノードの1つのアドレスとクラスター名のみが必要です。
garbd -a gcomm://192.168.1.1:3400 -g cluster0
テスト
テストパッケージから標準のsql-benchユーティリティをテストしました。最初にノードを個別にテストし、次にクラスターをテストしました。 ソフトウェアは同時に変更されませんでした-percona-xtradb-cluster。
テストパッケージをインストールして実行します。
apt-get install percona-server-test-5.5 libdbd-mysql-perl cd /usr/share/sql-bench/sql-bench/ perl run-all-tests --server=mysql --user=root --password=<password>
最初にSSDを搭載した2台の同一の高速マシンでテストしました。
最初の実行の結果は、後続の結果よりもはるかに優れていたため、破棄しました（純粋なSSDに書き込みます）。
これは1つのノードです。
alter-table: Total time: 17 wallclock secs ( 0.04 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.04 CPU) ATIS: Total time: 7 wallclock secs ( 2.48 usr 0.16 sys + 0.00 cusr 0.00 csys = 2.64 CPU) big-tables: Total time: 10 wallclock secs ( 1.87 usr 0.34 sys + 0.00 cusr 0.00 csys = 2.21 CPU) connect: Total time: 64 wallclock secs (19.80 usr 5.68 sys + 0.00 cusr 0.00 csys = 25.48 CPU) create: Total time: 548 wallclock secs ( 3.35 usr 1.66 sys + 0.00 cusr 0.00 csys = 5.01 CPU) insert: Total time: 531 wallclock secs (155.04 usr 19.15 sys + 0.00 cusr 0.00 csys = 174.19 CPU) select: Total time: 168 wallclock secs (17.93 usr 1.90 sys + 0.00 cusr 0.00 csys = 19.83 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 5 wallclock secs ( 1.31 usr 0.18 sys + 0.00 cusr 0.00 csys = 1.49 CPU)
これはクラスターです。
alter-table: Total time: 21 wallclock secs ( 0.04 usr 0.05 sys + 0.00 cusr 0.00 csys = 0.09 CPU) ATIS: Total time: 21 wallclock secs ( 2.76 usr 0.30 sys + 0.00 cusr 0.00 csys = 3.06 CPU) big-tables: Total time: 17 wallclock secs ( 1.98 usr 0.40 sys + 0.00 cusr 0.00 csys = 2.38 CPU) connect: Total time: 67 wallclock secs (21.13 usr 5.59 sys + 0.00 cusr 0.00 csys = 26.72 CPU) create: Total time: 597 wallclock secs ( 3.55 usr 1.55 sys + 0.00 cusr 0.00 csys = 5.10 CPU) insert: Total time: 1710 wallclock secs (164.66 usr 35.25 sys + 0.00 cusr 0.00 csys = 199.91 CPU) select: Total time: 187 wallclock secs (19.49 usr 2.44 sys + 0.00 cusr 0.00 csys = 21.93 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 47 wallclock secs ( 1.62 usr 0.88 sys + 0.00 cusr 0.00 csys = 2.50 CPU)
書き込み操作の3倍の低下と、ウィスコンシンテストの重大な（エピックではないにしても）低下。理論的には、読み取り操作と書き込み操作が交互に行われるはずです。
なぜ取引を誓うのかわかりません。 実際、彼らは働いています。
すべてがネットワークの速度に依存するという仮定があったため、ハードドライブを搭載したマシン（同一ではない）でテストしました。
最初のノードは別です：
alter-table: Total time: 55 wallclock secs ( 0.04 usr 0.02 sys + 0.00 cusr 0.00 csys = 0.06 CPU) ATIS: Total time: 10 wallclock secs ( 2.40 usr 0.14 sys + 0.00 cusr 0.00 csys = 2.54 CPU) big-tables: Total time: 7 wallclock secs ( 1.23 usr 0.15 sys + 0.00 cusr 0.00 csys = 1.38 CPU) connect: Total time: 53 wallclock secs (16.31 usr 7.65 sys + 0.00 cusr 0.00 csys = 23.96 CPU) create: Total time: 3215 wallclock secs ( 2.58 usr 0.83 sys + 0.00 cusr 0.00 csys = 3.41 CPU) insert: Total time: 541 wallclock secs (142.41 usr 22.53 sys + 0.00 cusr 0.00 csys = 164.94 CPU) select: Total time: 154 wallclock secs (12.66 usr 1.34 sys + 0.00 cusr 0.00 csys = 14.00 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 4 wallclock secs ( 1.15 usr 0.29 sys + 0.00 cusr 0.00 csys = 1.44 CPU)
2番目のメモは別です。
alter-table: Total time: 59 wallclock secs ( 0.03 usr 0.03 sys + 0.00 cusr 0.00 csys = 0.06 CPU) ATIS: Total time: 11 wallclock secs ( 2.35 usr 0.23 sys + 0.00 cusr 0.00 csys = 2.58 CPU) big-tables: Total time: 11 wallclock secs ( 1.92 usr 0.30 sys + 0.00 cusr 0.00 csys = 2.22 CPU) connect: Total time: 64 wallclock secs (19.67 usr 5.84 sys + 0.00 cusr 0.00 csys = 25.51 CPU) create: Total time: 4592 wallclock secs ( 3.90 usr 1.39 sys + 0.00 cusr 0.00 csys = 5.29 CPU) insert: Total time: 581 wallclock secs (148.16 usr 19.80 sys + 0.00 cusr 0.00 csys = 167.96 CPU) select: Total time: 168 wallclock secs (18.45 usr 2.07 sys + 0.00 cusr 0.00 csys = 20.52 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 5 wallclock secs ( 1.18 usr 0.25 sys + 0.00 cusr 0.00 csys = 1.43 CPU)
クラスター：
alter-table: Total time: 110 wallclock secs ( 0.04 usr 0.02 sys + 0.00 cusr 0.00 csys = 0.06 CPU) ATIS: Total time: 496 wallclock secs ( 1.61 usr 0.17 sys + 0.00 cusr 0.00 csys = 1.78 CPU) big-tables: Total time: 116 wallclock secs ( 1.02 usr 0.16 sys + 0.00 cusr 0.00 csys = 1.18 CPU) connect: Total time: 34 wallclock secs (10.98 usr 2.49 sys + 0.00 cusr 0.00 csys = 13.47 CPU) create: Total time: 4638 wallclock secs ( 2.42 usr 0.91 sys + 0.00 cusr 0.00 csys = 3.33 CPU) insert: Estimated total time: 43470.8 wallclock secs (106.50 usr 15.34 sys + 0.00 cusr 0.00 csys = 121.84 CPU) select: Total time: 631 wallclock secs (11.02 usr 1.02 sys + 0.00 cusr 0.00 csys = 12.04 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 1576 wallclock secs ( 1.37 usr 0.44 sys + 0.00 cusr 0.00 csys = 1.81 CPU)
ただし、この仮定は確認されていません。クラスター内のハードドライブコンピューターでの書き込み操作が10倍も遅くなりました。 これを説明する方法-私は知りません。
実際の生産での使用に関しては、誰もが自分で選択します。 私にとって、このようなパフォーマンスの相対的な低下は、絶対数が小さいため重要ではありません。
考えられる問題とその解決方法
1。
WSREP: Process completed with error: wsrep_sst_xtrabackup 'donor' '192.168.1.1:6000/xtrabackup_sst' 'backup:password' '/var/lib/mysql2/' '/etc/mysql/my2.cnf' '9bdd7773-0cb4-11e2-0800-8e876ebc6b70' '0' '0': 22 (Invalid argument)
xtrabackupはデータベースに接続できませんでした。 同じマシン上に複数のノードを作成しようとしていませんか？ 詳細は、innobackup.backup.logを参照してください。
2。
121002 15:19:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql0 /usr/bin/mysqld_safe: 172: [: gcomm://: unexpected operator
bashの代わりに、別のインタープリターが使用されます。 mysqld_safeの最初の行を変更するか、シンボリックリンクを編集します。
3. MyISAMテーブルが作成されているが、ダンプから生成されていない場合は、InnoDBのみがサポートされているはずです。
4.すべてのコマンドがデータの書き込みまたは読み取りを行う場合、MySQLクライアントは「不明なコマンド」を発行します。これは、ノード間の接続が切断された場合のスプリットブレインに対する保護です。