問題タブ [galera]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
mysql - Galera ノードがクラスターに接続できない
こんにちは、10.1.12-MariaDB で Galera を使用しています。SST メソッドは xtrabackup-v2 です。
SST=rsync を推奨しないでください。私にはうまくいきません
正常なクラスター 8 ノードがありますが、1 つまたはいくつかのノードがダウンすることがあります。私はそれを開始するだけservice mysqlで、クラスターに正常に接続し、すべて問題ありません。
しかし、時々、切断されたノードが数日ダウンすると、それらをクラスターに接続できなくなります。
数回試行した後、何もしないと、syslog に次のメッセージが表示されますrm -fr /var/lib/mysql/*。rm -fr /var/log/mysql/*
mysqld: [ERROR] Binlog file '/var/log/mysql/mariadb-bin.003079' not found in binlog index, needed for recovery. Aborting.
上記のメッセージでクラスターに接続できないノードがある場合、クラスターを回復できるので、次のようにします。
- すべてのノードをシャットダウンし、1 つのノードだけを残す
- 最後のノードをシャットダウンし、
rm -fr /var/log/mysql/* - 削除された binlog を使用して、この最後のノードをブートストラップします
- 他のノードをクラスターに接続する
service mysql start - 利益 - すべてOK
しかし、問題は次のとおりです。
私はすべての本番ノードをダウンすることはできず、最後のノードもダウンします。これは、大きなサイト トラフィックを処理する 8 つのノードがあり、すべてのトラフィックがそこに行くとすぐに 1 つの実行中のノードがダウンするためです (もちろん、過負荷のため)。
質問は:
私を助けてください。ノードが接続されず、エラーが発生した場合に、ノードをクラスターに接続する方法mysqld: [ERROR] Binlog file '/var/log/mysql/mariadb-bin.003079' not found in binlog index, needed for recovery. Aborting.
mysql - mariadb 10.1.13 galera クラスター: エラー
mariadb 10.1.x galera クラスター設定。
最初のノード 192.168.159.132
/etc/mysql/my.cnf
最初のノード 192.168.159.132
$ sudo サービス mysql ブートストラップ
$ systemctl status mariadb.service
「Galera Cluster」が起動しないのはなぜですか?
「接続タイムアウト」の確認方法
mysql - MariaDB Galera クラスターが同期していません
以前に MariaDB クラスターをデプロイしたことがありますが、この問題は最近発生したばかりです (以前はこの問題は発生しておらず、理由もわかりません)。
サーバー 1、2、および 3 があります。サーバー 3 で INSERT コマンドを実行しましたが、サーバー 1 と 2 のテーブルは変更されません。
3 つのサーバーが世界のさまざまな場所にあります。After the INSERT command, the state uuid remains the same.
サーバー 1 のステータスは次のとおりです。
MariaDB [mysql]> show status like 'wsrep_%';
+------------------------------+----------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------+
| wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 205 |
| wsrep_replicated | 170 |
| wsrep_replicated_bytes | 160481 |
| wsrep_repl_keys | 664 |
| wsrep_repl_keys_bytes | 9222 |
| wsrep_repl_data_bytes | 140379 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 46 |
| wsrep_received_bytes | 26150 |
| wsrep_local_commits | 170 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 1 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 1 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_local_cached_downto | 1 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 7.482927 |
| wsrep_apply_oooe | 0.009756 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.009756 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 28 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.009756 |
| wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0.200155/0.201113/0.201752/0.000614937/4 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | c4f91b4f-fee1-11e5-8c4f-6e451c332f79 |
| wsrep_cluster_conf_id | 3 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 6 |
| wsrep_local_index | 0 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.14(r3560) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------+
サーバー 2 のステータス:
MariaDB [(none)]> show status like 'wsrep_%';
+------------------------------+----------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------+
| wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 225 |
| wsrep_replicated | 35 |
| wsrep_replicated_bytes | 25700 |
| wsrep_repl_keys | 119 |
| wsrep_repl_keys_bytes | 1757 |
| wsrep_repl_data_bytes | 21703 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 187 |
| wsrep_received_bytes | 177793 |
| wsrep_local_commits | 35 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 1 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 4 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.032086 |
| wsrep_local_cached_downto | 9 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 7.193548 |
| wsrep_apply_oooe | 0.004630 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.004630 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 28 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.009217 |
| wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0.200138/0.201917/0.203696/0.00177914/2 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | d562e272-fee1-11e5-b2a2-d3a6b5579aab |
| wsrep_cluster_conf_id | 3 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 1 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.14(r3560) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------+
57 rows in set (0.01 sec)
server3 のステータス (ご覧のとおり、レイテンシーはすべて 0 を示していますが、理由はわかりません)
MariaDB [(none)]> show status like 'wsrep_%';
+------------------------------+----------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------+
| wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 245 |
| wsrep_replicated | 5 |
| wsrep_replicated_bytes | 4350 |
| wsrep_repl_keys | 11 |
| wsrep_repl_keys_bytes | 203 |
| wsrep_repl_data_bytes | 3827 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 226 |
| wsrep_received_bytes | 208559 |
| wsrep_local_commits | 1 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 1 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_local_cached_downto | 19 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 7.022026 |
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.000000 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 28 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.008811 |
| wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0/0/0/0/0 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | fd022144-fee1-11e5-a7a3-f23274fef9c3 |
| wsrep_cluster_conf_id | 3 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 2 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.14(r3560) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------+
57 rows in set (0.00 sec)
3 つのサーバーすべての iptables は、すべての入出力トラフィックを ACCEPT するように設定されています。
ログは、すべてのサーバーがクラスターに参加して同期したことを示しています。
誰かが理由を知っていますか？ありがとう。
cluster-computing - 非マスターノードが更新されると、MariaDB クラスターからクラスターへのレプリケーションが機能しない
2 つの MariaDB Galera クラスター (PROD (サーバー A、B、および C) と DR (サーバー 1、2、および 3)) があります。 DR クラスターのプライマリ コンポーネント ノード (サーバー 1) への PROD クラスター 各クラスターは、通常どおり、他のクラスターとは独立して動作できます (つまり、1 つのノードに変更を加えると、クラスター内のすべてのノードが直ちに変更をレプリケートします)。
この構成の目的は、スレーブでのリレー ログの適用を所定の時間遅らせることができるようにすることです。残念ながら、MariaDB 10.1 は MySQL 5.6/7 遅延リレー ログ アプリケーションをサポートしていません。Percona スクリプトを使用してスレーブ プロセスの制御を容易にし、リレー ログが DR クラスターに適用されるまでの時間を変更できるようにしています。
PROD クラスターのプライマリ コンポーネント ノード (マスター - サーバー A) に直接変更が加えられると、その変更はすぐに DR クラスターのプライマリ コンポーネント ノード (スレーブ - サーバー 1) にレプリケートされ、次にすべてのノードにレプリケートされます (サーバー 2 および 3) を DR クラスター内に配置します。ただし、プライマリ コンポーネント ノード (サーバー A) ではない PROD クラスタ内のノード (サーバー C など) に変更を加えた場合、それらの変更は DR プライマリ コンポーネント ノード (スレーブ - サーバー 1) に複製されません。
バイナリ ログを駆動するプロセスは、ポート 4567 で実行されている wsrep クラスタ レプリケーション プロセスによって明らかになった PROD クラスタの変更をリッスンしていないため、バイナリ ログ ファイルに書き込まれていないのではないかと思われます。
PROD クラスターの任意のノードでの変更が、クラスターのプライマリ コンポーネント ノード (マスター - サーバー A) のバイナリ ログを介してレプリケートされるように、MariaDB を構成する方法はありますか?
ありがとう。
laravel-5 - MariaDB Galera Cluster (読み取り/書き込みユーザー) で使用すると、PHPUnit テストがランダムに失敗する
MariaDB Galera Cluster に対して実行する Laravel (Lumen 5.2) プロジェクトがあります。アプリを実行すると、問題なく動作するようです。しかし、PHPUnit テストを実行すると、ランダムに失敗します。
問題は、データベースにデータを入力してから、データ (id) を取得して他のテーブルに外部キーを入力しようとすることです。しかし、直後にデータを取得しようとすると、データが null になります。
Laravel データベース接続は、READ ユーザーと WRITE ユーザーで使用されます。（Laravelは、挿入または読み取り時に正しいものを自動的に使用します）。そして、これはどういうわけか問題だと思います。WRITE ユーザーのみを使用すると、テストは問題なく動作します。
mysql - Mysql の RAM 使用率が高い
私は 5 つのノードを持つ MariaDB ガレラ クラスターを使用しています。バージョン: 1.3.0.1242 CMON API バージョン: 1.3.0.183
すべてのノードは 60 GB の RAM であり、サーバーの 1 つはより多くの RAM を消費し、同時に他の 4 つのノードは正常に動作しています。
mariadb1 サーバーで RAM の使用量を減らすにはどうすればよいですか?
これに対する解決策を提供してください。
containers - コンテナーの再起動に関する問題、ランチャーの Galera MariaDB スタック
- こんにちは、docker compose を使用して wordpress アプリケーションを作成しようとしています。ランチャーの Galera MariaDB カタログ エントリを使用しています。
すべてのセットアップを正常に機能させることができます。外部リンクを使用し、次のような環境変数を使用してロード バランサーに接続します。
外部リンク：
- r-galera_galera-lb_1:mysql
クラスター内でテーブルが複製されているのを確認できますが、マシンを再起動すると、スタックが再びアクティブになった後でも、アプリケーションを起動できません。
次のようなエラーが表示されます。
Galera スタック全体を削除して新しいスタックを作成すると、ワードプレスのセットアップが再び機能します。
カタログのメンテナーと連絡が取れなかったため、この問題についてこのフォーラムに来なければなりませんでした (連絡先情報がありません)。誰かがこの点で助けることができますか?
mysql - Mysql Update クエリに時間がかかる
このテーブルに 1 つの列 (numviews) を持つ 1 つの mysql テーブルがあり、頻繁に更新されます (同じ更新クエリがループで実行されます)。2 秒以上の時間がかかっており、このテーブルに依存しているアプリケーションにも影響を与えたり遅くしたりしているため、これを改善する方法を見つけることができません。これがmysqlテーブルです。
注: これは innodb テーブルであり、他に遅いクエリはありません。このテーブルは、mariadb galera クラスターの下にあります。私も300の最大接続を持っています。どの時点でも、グローバル接続は 170/180 を超えません。
そして、これがループで実行されるmysql更新クエリです（このテーブルで以下のクエリが約50回実行されます）。
編集:デッドロックも見られます。
この更新クエリを改善する方法を教えてもらえますか?