問題タブ [galera]

いくつかのデータを含む MySQL データベースがあります。今、このデータベースからクラスターを作成したいと思います。

私はすでに Galera を構成しており、この単一のノードしかありません。では、データを別のノードに複製する方法は?

それは Galera によって自動的に行われますか、それとも現在のデータを最初にダンプしてから、最初のノードの DB をクリーンアップし、他のすべてのノードを起動してデータをそれらの 1 つにロードし、それらが複製されるのを待つ必要があります。

次の質問は、実行時にノードを追加/削除する方法ですか?

2 つのサーバーでアプリケーションを実行しています。それらのそれぞれで実行されているmariadbと、レプリケーションを処理するgaleraクラスターがあります.

アプリをアップグレードするときはレプリケーションを停止する必要があるため、サーバーの 1 つに対してクラスター外でデータベースを起動する方法と、それを再接続する最善の方法についてのガイドラインが必要でした。

すべてのアイデアを歓迎します よろしくお願いします

ガレラ星団に興味があります。Galera チームは、さまざまな GCS に対応する柔軟なアダプター ベースの設計を行っていると主張しています。

http://galeracluster.com/products/technology/彼らのウェブサイトには、「多くの gcs 実装を適応させることができます。私たちは拡散と社内実装を実験しました: vsbes とジェミニ」と述べていますが、実装に関するリソースをオンラインで見つけることはほとんどできません。スプレッド (分散ツールキット) と Galera クラスターを組み合わせる方法。

小さなgaleraクラスターをセットアップすると、うまく機能します。1 つの Mysql を更新すると、他の mysql も更新されました。Galera がスプレッドを扱う必要がある理由とその方法について混乱しています。ガレラでスプレッドを実装する方法を知っている人はいますか?

どうもありがとう。

単一の MySQL データベース サーバーで 12 か月間実行されている Drupal アプリケーションがあり、(ピーク負荷イベントを除いて) 比較的良好に動作しています。現在の DB サーバーが許容するよりもはるかに高いスパイクをサポートできるようにする必要があり、32 GB では、単一の DB サーバーを単純に垂直方向にスケーリングするだけではあまりメリットがありませんでした。

2 つの 32GB インスタンスを備えた新しい MariaDB Galera クラスターをセットアップすることにしました。間もなく廃止されるDBサーバーと可能な限り構成を一致させました。

新しいデータベース サーバーに移行した後、これらのインスタンスの CPU 使用率が常に 100% であり、負荷が着実に増加していることに気付きました。1 時間の間に、負荷平均は 0.1 から 150 になりました。

当初はサーバー間の同期に関係があるのではないかと考えていましたが、1 台のサーバーがオフになっていて同期が行われていない場合でも、Web アプリケーションがサーバーにリクエストを送信している限り、CPU を使い果たしていました。

多くの実験の後、いくつかの構成オプションを減らすと、CPU 使用率と負荷に大きな影響があることがわかりました。以下の変更を行った後、負荷平均は両方のインスタンスで 4 ～ 6 の間で安定しました。

質問

• 基本的に古いサーバーから構成を移行しているにもかかわらず、古いサーバーと新しいサーバーの間で CPU 使用率が劇的に異なる理由として考えられるものは何ですか?
• 現在、負荷は 4 ～ 6 の間で推移しています (これは、Web サイトのトラフィックが少ない期間です)。この値を減らして、サイトが実際のトラフィックに見舞われたときにフォールオーバーしないようにするには、何を確認する必要がありますか?

構成の変更

innodb_buffer_pool_instances

• 元の値: 500 (すべてのデータベースで合計 498 のテーブルがあります)
• 新しい値: 92

table_cache

• 元の値: 8
• 新しい値: 4

最大接続数

• 元の値: 1000
• 新しい値: 400

現在の構成

これは、サーバーの1つからの完全な構成ファイルです/etc/mysql/my.cnf

xtrabackup_v2 SST を使用して galera クラスターに 3 番目のノードを追加しようとしていますが、エラーが発生し続けます:

バイナリ ログを見ると、mariadb-bin.state ファイルが空であるように見えます。これが問題の原因です。

ドナー サーバーの binlog ディレクトリを見ると、「mariadb-bin.state」ファイルがありません。

アプリケーション用に 3 ノードの galera クラスターをセットアップしました。アプリケーションには一時的にテーブルを作成する特定のストアド プロシージャがあり (TEMPORARY TABLE ではありません)、テーブルは動的に作成されて実行されます。一部の CRUD 操作はテーブルに対して複数回実行され、その使用が完了すると、ストアド プロシージャの最後に削除されます。問題は、この特定のストアド プロシージャを実行するたびに、3 つのノードのうち 2 つが失敗し、自動的にシャットダウンすることです。失敗したノードからのログは次のとおりです:-

ストアドプロシージャの内部構造を変更せずにこれを解決できる特定のものがあります。

の出力

スタックオーバーフローの「MySQLのデッドロック」など、他の同様の問題を確認しましたが、解決策はありません。

状況：

1. すべてのテーブルはInnoDBです。db1.table1 =>照合: latin1_swedish_ci および db2 の場合 =>照合: utf8_unicode_ci
2. クエリは、バージョンが Server version: 10.0.15-MariaDB である開発サーバーで正常に機能します。
3. Galera cluster を使用してマルチマスター レプリケーションを共有する 5 つの DB サーバーがあるとします。
4. これら 5 つのサーバーのいずれかで手動でクエリを実行すると、エラーが発生します。
5. そのサーバーのバージョンは、クエリの実行が成功した開発サーバーと同じです。つまり、10.0.15-MariaDB です。

試した：

1. LOCK IN SHARE MODEが含まれています。例: REPLACE INTO... (最初の選択クエリ (サブクエリ) LOCK IN SHARE MODE); しかし、同じメッセージで失敗しました。
2. Insert / REPLACE ... (最初の選択クエリ (サブクエリ LOCK IN SHARE MODE) LOCK IN SHARE MODE); また、同じメッセージで失敗しました。
3. 選択クエリ/サブ選択クエリでIDによる順序付けを試みました。再び同じメッセージで失敗しました。
4. db1.table1 と db2.table1 のレコードはどちらもほぼ 50k しかないため、問題は発生しないはずです。
5. すべてのテーブルには、主キーとしての id と自動インクリメントがあります。しかし、私はどういうわけかそれらを明示的に使用しています-クエリを観察してください。
6. エンジンの INNODB ステータスを表示します。私に役立つヒントを追加しません。

最も可能性の高い理由は、楽観的ロックのための galera クラスターの背後にあるマルチマスター レプリケーションが原因である可能性があります( http://www.severalnines.com/blog/avoiding-deadlocks-galera-set-haproxy-single-node-writes-and -multi-node-reads )。しかし、個々のノードでクエリを実行するときに失敗するべきではありませんか? 成功したら、そのマルチマスターレプリケーションで同じことを実行する必要がありますが、基本的な問題が解決されれば、レプリケートされたサーバーで問題が発生することはないと思います。

ノート：

一時テーブルを使用したり、サブクエリの結果をコードに保存したりせずに、これを行う必要があります。これまでのところ、単一のクエリを実行することが最も好ましい方法である依存関係が他にもいくつかあります。

Debian Wheezy 7.5 で mariadb galera クラスターをセットアップしようとしています。私は多くの異なる指示を見つけましたが、すべて少し異なりますが、これまでのところ機能していません。

2 ノード クラスタをセットアップしようとしています。

プライマリ ノードでは、デフォルトの my.cnf を使用しており、conf.d/cluster.cnf に次の追加設定があります。

クラスターユーザーを作成し、そのユーザーに必要なすべての権限を付与し、サーバーを正常に起動しました

クラスターが起動しますcluster_size=1。

2 番目のノードでは、デフォルトの my.cnf を使用しており、conf.d/cluster.cnf に次の追加設定があります。

また、この提案に従って、セカンダリ ノードの debian.cnf をプライマリ ノードの debian.cnf に置き換えました。

http://docs.openstack.org/high-availability-guide/content/ha-aa-db-mysql-galera.html適切なパーミッションを付与します (これは他の場所でも提案されていましたが、リンクが正しくありません今）。

両方のノードの debian.cnf の内容:

2 番目のノードを起動しようとすると、次のようになります。

service mysql start

失敗し、/var/log/syslog に次のように表示されます。

この質問には、インターネット全体に無数のスレッドがあります。答えのないものもあります。答えがあるもののいくつか

エラー 2002 (HY000): ソケット '/var/run/mysqld/mysqld.sock' (111) を介してローカル MySQL サーバーに接続できません- ディスク容量がいっぱいではありません

ソケット '/var/run/mysqld/mysqld.sock' を介してローカル MySQL サーバーに接続できません- 応答がありません。しかし、コメントによると、mysql.sock は存在し、mysql.mysql の所有権を持っています。

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - サーバーがインストールされていますが、ソケットは正しい場所に存在します

これは /var/run/mysqld の権限の問題である可能性があることも読みましたが、これを確認して mysql.mysql の所有権を与えました。

少なくとも、これはこの問題を復活させる試みです。どんな方向でも本当に感謝しています。

ありがとうございました、

更新: 両方のノードの my.cnf。デフォルトの my.cnf です。唯一の変更点は、行をコメントアウトすることbind-address=127.0.0.1です。

更新 また、テストしました。ノードを定期的に起動しようとすると、(クラスターなしで、追加の設定なしで、デフォルトのみで) 動作します。