MySQLは間違ったパスワードを入力する試行回数を制御します

1. 本番環境でMySQLのデッドロックを監視し、デッドロックの可能性を減らす方法

まず、デッドロックは「ロック」されているわけではありません。デッドロックは、ループを待機している 2 つ以上のセッション ロックによって発生します。

1. デッドロックの監視と処理方法

デッドロック監視のために、各バージョンでは innodb_print_all_deadlocks オプションが提供されています。このオプションをオンにすると、デッドロック ログが MySQL エラー ログに出力されます。したがって、エラー ログを監視することで、デッドロック監視の目的を達成できます。 MariaDB の場合はさらに簡単です。MariaDB は Innodb_deadlocks カウンターを提供しており、これを使用してカウンターの増加を監視し、デッドロックを検出することができます。
オンラインでデッドロックが発生し、その頻度が高い場合は、深刻に受け止める必要があります。デッドロック ログには、デッドロックの原因となった最後の 2 つの SQL ステートメントのみが記録されるため、デッドロック ログからデッドロックの原因をすぐに特定することはできません。開発者と迅速に協力してデッドロック プロセスをシミュレートし、デッドロックの原因を分析し、プログラム ロジックを修正する必要があります。

2. デッドロックの可能性を減らす方法

1. 短い取引を使用し、大きな取引を避けるようにしてください
2. FOR UPDATE/LOCK IN SHARE MODE ロックを追加する場合は、デッドロックの可能性を減らし、ロックの粒度を下げるために、RC レベルなどのトランザクション分離レベルを下げるのが最適です。
3. トランザクションが複数のテーブルまたは複数のレコード行に関係する場合、各トランザクションの操作順序は一貫している必要があります。
4. インデックスを通じてSQLの効率を最適化し、デッドロックの可能性を減らし、フルテーブルスキャンによる全データのロックを回避する
5. プログラムにはトランザクションの失敗検出と自動再送信のメカニズムが必要です
6. 同時実行性が高い（フラッシュセール）シナリオでは、innodb_deadlock_detectオプションをオフにして、デッドロック検出のオーバーヘッドを減らし、同時実行性効率を向上させます。

2. MongoDBの優れた機能と適したシナリオは何ですか？

1. 優れた特性

1. 実用性: JSONのようなリッチドキュメントデータモデルで、開発者にとって自然に使いやすい
2. 可用性: ラフトプロトコルに基づく自動高可用性により、99.999%の可用性を簡単に提供
3. スケーラビリティ: シャードクラスタのサポートにより、ビジネスに優しい水平拡張が実現します。
4. 高性能: ネストされたモデル設計のサポート、個別の書き込みの削減、物理メモリの完全な利用、ディスク読み取りの回避
5. 強力な圧縮: WiredTiger エンジンは、さまざまなデータ圧縮戦略を提供し、圧縮率は 2 ～ 7 倍で、ディスク リソースを大幅に節約します。

（II）適切なシナリオ

1. 複数ドキュメントのトランザクションや複数テーブルの関連付けクエリは不要
2. ビジネスの反復が速く、需要の変化が頻繁な業界
3. 単一クラスタでは同時実行性が高すぎるため、ビジネスの成長をサポートできない
4. データ量の増加はTB以上のストレージ要件に達すると予想されます
5. 99.999%のデータベース高可用性シナリオを期待する

3. 他のプログラミング言語と比較した GO 言語の利点は何ですか?実際の生産環境ではどのように選択すればよいでしょうか?

1. 高い並行性、強い一貫性のある言語、高い開発効率、安定した安全なオンライン操作を自然にサポート
2. ガベージコレクション、メモリの割り当てとリサイクルを心配する必要がない
3. 強力なGMPモデル、非同期処理、高並列性のサポートにより、初心者でも簡単に高並列性コードを書くことができます。

実際の運用環境では、次の点を考慮することをお勧めします。

1. ビジネスシナリオを見ると、電子商取引とビッグデータ処理には既成のソリューションがありますが、それらは使用に適していません。さらに、CPU を集中的に使用する数学演算も必要ありません。
2. GOはビジネスプロトタイプを素早く作成するのに優れており、反復開発の効率が高いため、スタートアップに強く推奨されています。
3. 会社が開発したテクノロジー スタックを確認します。大きな違いがある場合は、GO を選択すると、開始しやすくなり、プログラミング スタイルを統一できます。

4. 多数の更新を含む大規模なトランザクションがロールバックされましたが、急いでシャットダウンして再起動する必要があります。どうすればよいでしょうか?

1. まず、大規模なトランザクションはマスターとスレーブ間のレプリケーションの遅延などの問題を引き起こすため、MySQL で大規模なトランザクションを実行しないようにしてください。
2. 大規模なトランザクションが強制終了されると、MySQL は自動的にトランザクションをロールバックします。ROLLING BACK トランザクションは、show engine innodb status の TRANSACTIONS で確認できます。ロールバック操作中は、対応する行ロックは保持されたままになります。
3. この時点で MySQL を強制的にシャットダウンした場合でも、MySQL の再起動後にロールバック操作は実行されます。
4. したがって、データのセキュリティを確保するために、シャットダウンして再起動する前に、ロールバックが完了するまで辛抱強く待つことをお勧めします。シャットダウンして再起動する前に、innodb_max_dirty_pages_pctを下げてダーティページをできるだけ多くリフレッシュし、innodb_fast_shutdownをオフにすることができます。
5. コンピュータをシャットダウンする他の方法がない場合、kill -9 を使用して最初に MySQL をシャットダウンできます。前提として、トランザクションのセキュリティを確保するために double-one を設定する必要があります。そうしないと、より多くのトランザクション データが失われる可能性があります。その後、インスタンスを再起動すると、InnoDB は自動的にクラッシュリカバリを実行し、以前のトランザクションをロールバックします。

PS、kill -9 はリスクの高い操作であり、MySQL の起動に失敗するなどの予期しない問題が発生する可能性があるため、注意して使用してください。

5. UPDATE/DELETE 中に WHERE 条件が間違っていたり、WHERE 条件がなかったりした場合の影響を軽減する方法

1. 間違いが起きやすいので、SQL コマンドをオンラインで手動で実行しないようにしてください。 SQLコマンドをオンラインで直接実行する場合は、確認のために2人目の人がいるのが最善です。
2. 本番環境で実行する前にテスト環境でSQLを実行して正しいことを確認するか、事前にローカルテキスト環境で編集して実行する前に確認するのが最適です。
3. WHERE 条件、LIMIT 条件、またはインデックス条件のない UPDATE/DELETE コマンドの実行を禁止するには、sql_safe_updates オプションをオンにすることをお勧めします。 mysqlクライアントでサーバーに接続するときに、--safe-updatesオプションを追加することもできます。例：mysql --safe-updates -h xx -u xx
4. DML 操作をオンラインで手動で実行する場合は、誤った操作が発生した場合にロールバックできるように、まずトランザクション モードを有効にします。たとえば、mysql> begin; update xxx; rollback;
5. DB管理プラットフォームを介してDML操作を実行し、プラットフォーム上でそのような危険なSQLに対する判断を追加して、危険なSQLの実行を直接拒否します。
6. 誤ってデータを削除した後、遅延スレーブデータベースからデータを迅速に復元できるように遅延スレーブデータベースを構成する

6. ユーザーが間違ったパスワードを入力した場合、MySQL は試行回数をどのように制御しますか?

1. プラグインのサポート

公式 MySQL 5.7.17 以降では、CONNECTION_CONTROL および CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS プラグインが提供され、connection_control_failed_connections_threshold、connection_control_min_connection_delay、connection_control_max_connection_delay の 3 つのパラメータが提供されます。

1. 接続制御失敗接続しきい値

このパラメータの意味は、ログインを遅らせる前にログイン失敗の回数を制御することです。

2. 接続制御最小接続遅延

このパラメータは、失敗回数が制限を超えた後の各再接続の最小遅延時間を示します。遅延の計算式は、(現在の失敗回数合計 - 失敗しきい値) connectioncontrolminconnection_delay です。したがって、エラー試行回数が多いほど、遅延時間は長くなります。

3. 接続制御最大接続遅延

クライアントが再接続できるまでの最大遅延時間

4. プラグインをインストールした後、Connection_control_delay_generatedステータス値とINFORMATION_SCHEMAの下のテーブルを監視できます。

CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS は失敗したログイン試行回数を監視します。

2. エラーログ監視

MySQL エラー ログを定期的にスキャンしてアカウントとパスワードのエラーの数を記録し、一定のしきい値に達すると、対応するホスト IP をシステム ファイアウォールでブロックして、アカウントをブロックする目的を達成できます (具体的な操作は状況によって異なります)
たとえば、エラー ログには 2019-05-10T13:04:41.232259Z 5 [注] ユーザー 'xucl'@'127.0.0.1' のアクセスが拒否されました (パスワード使用: YES) と表示されます。

（III）その他の指示

1. 一部の学生は、max_connection_errors が間違ったパスワードの試行回数を制御できると誤解しています。実際には、このパラメータは、telnet などのポート検出を防ぐこと、つまりプロトコル ハンドシェイク エラーの数を記録することしかできません。

2. 最後に、実稼働環境では、aborted_clients と aborted_connects のステータスに注意し、例外がないか適時に確認する必要があります。

要約する

以上が、ユーザーが間違ったパスワードを入力したときの試行回数を制御する MySQL についてご紹介したものです。お役に立てれば幸いです。ご質問がございましたら、メッセージを残していただければ、すぐに返信いたします。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。
この記事が役に立ったと思われた方は、ぜひ転載していただき、出典を明記してください。ありがとうございます!