MySQL Shellの紹介とインストール

MySQL Shellの紹介とインストール

01 レプリ​​カセットアーキテクチャ

前回の記事では、ReplicaSet の基本的な概念と制限、および導入前の基礎知識について説明しました。今日は、InnoDB ReplicaSet のデプロイメント プロセスにおける 2 つの重要なコンポーネントのうちの 1 つである MySQL Shell について説明します。MySQL Shell をよりよく理解するために、次の図を描きます。

上図から、MySQL Shell は運用保守担当者が基盤となる MySQL ノードを管理するためのエントリ ポイント、つまり DBA が管理コマンドを実行する場所であり、MySQL Router はアプリケーション接続のエントリ ポイントであることが容易にわかります。その存在により、基盤となるアーキテクチャがアプリケーションに対して透過的になります。アプリケーションは、基盤となるデータベースと対話するために MySQL Router に接続するだけでよく、データベースのマスター スレーブ アーキテクチャは MySQL Router の元の情報に記録されます。

今日は主にMySQL Shellの構築プロセスを見ていきます。

02 MySQL Shellの紹介とインストール

MySQL Shell は、Innodb Cluster または Innodb ReplicaSet を管理するために使用されるクライアント ツールです。簡単に言えば、ReplicaSet へのエントリ ポイントとして理解できます。

インストール プロセスは比較的簡単です。MySQL の公式 Web サイトから対応するバージョンの MySQL Shell をダウンロードするだけです。住所は以下の通りです。

https://downloads.mysql.com/archives/shell/

ここではバージョン8.0.20が使用されています

ダウンロード後、Linux サーバー上で解凍すると、この MySQL Shell を介してオンライン MySQL サービスに接続できます。

私のオンライン MySQL アドレスは次のとおりです:

192.168.1.10 5607

192.168.1.20 5607

次のコマンドを使用して、MySQL サービスに直接接続できます。

/usr/local/mysql-shell-8.0.20/bin/mysqlsh '$user'@'$host':$port --password=$pass

接続成功後のログは次のようになります。

MySQL シェル 8.0.20

Copyright (c) 2016, 2020, Oracle およびその関連会社。無断複写・転載を禁じます。
Oracle は、Oracle Corporation およびその関連会社の登録商標です。
その他の名称はそれぞれの所有者の商標である場合があります。

ヘルプを表示するには「\help」または「\?」と入力してください。終了するには「\quit」と入力してください。
警告: コマンド ライン インターフェイスでパスワードを使用すると安全でない可能性があります。
'[email protected]:5607' へのセッションを作成しています
自動補完用のスキーマ名を取得しています...停止するには ^C を押してください。
MySQL接続IDは831です
サーバーバージョン: 8.0.19 MySQL コミュニティサーバー - GPL
デフォルトのスキーマが選択されていません。設定するには \use <schema> と入力してください。
 MySQL 192.168.1.10:5607 ssl JS >
  MySQL 192.168.1.10:5607 ssl JS >
  MySQL 192.168.1.10:5607 ssl JS >
  MySQL 192.168.1.10:5607 ssl JS >

03 MySQL Shellはデータベースに接続し、レプリカセットを作成します

上記では、MySQL Shell を使用してデータベースに接続する方法を紹介しました。次に、MySQL Shell を使用して ReplicaSet を作成する方法を見てみましょう。

1. まず、dba.configureReplicaSetInstance コマンドを使用してレプリカ セットを構成し、レプリカ セットの管理者を作成します。

MySQL 192.168.1.10:5607 ssl JS > dba.configureReplicaSetInstance('[email protected]:5607',{clusterAdmin:"'rsadmin'@'%'"})
InnoDB ReplicaSet で使用するために 192.168.1.10:5607 の MySQL インスタンスを構成しています...

このインスタンスは自身のアドレスを192.168.1.10:5607として報告します。
警告: ユーザー 'rsadmin'@'%' はすでに存在するため、作成されません。ただし、権限がありません。
アカウント 'rsadmin'@'%' には、InnoDB クラスターを管理するために必要な権限がありません:
GRANT OPTION を指定して、*.* の REPLICATION_APPLIER を 'rsadmin'@'%' に付与します。
Dba.configureReplicaSetInstance: アカウント 'root'@'192.168.1.10' には、InnoDB クラスターを管理するために必要な権限がありません。(RuntimeError)

ご覧のとおり、上記のコマンドでは、レプリカ セットのインスタンス 192.168.1.10:5607 を構成し、管理者アカウント rsadmin を作成しました。この管理者には clusterAdmin 権限があります。

返された結果には、ログインした root アカウントに replication_applier 権限がないため、root アカウントを使用して rsadmin アカウントを承認できないことを示すエラー メッセージがあります。 root アカウントに replication_applier 権限を追加した後、上記のコマンドを再実行すると、結果は次のようになります。

MySQL 192.168.1.10:5607 ssl JS > dba.configureReplicaSetInstance('[email protected]:5607',{clusterAdmin:"'rsadmin'@'%'"})
InnoDB ReplicaSet で使用するために 192.168.1.10:5607 の MySQL インスタンスを構成しています...

このインスタンスは自身のアドレスを192.168.1.10:5607として報告します。
ユーザー 'rsadmin'@'%' は既に存在するため、作成されません。

インスタンス '192.168.1.10:5607' は InnoDB ReplicaSet で使用できます。

インスタンス '192.168.1.10:5607' はすでに InnoDB ReplicaSet で使用できる状態になっています。

今回は処刑は成功しました。

基盤となる 192.168.1.10 にログインし、rsadmin アカウントを確認します。アカウントが生成されていることがわかります。情報は次のとおりです。

mysql.user から、user、host、concat(user,"@'",host,"'")、authentication_string を選択します。user は "%%rsadmin" のような文字列です。
+---------+------+----------------------------+------------------------------------------+
| ユーザー | ホスト | concat(user,"@'",host,"'") | 認証文字列 |
+---------+------+----------------------------+------------------------------------------+
| rsadmin | % | rsadmin@'%' | *2090992BE9B9B27D89906C6CB13A8512DF49E439 |
+---------+------+----------------------------+------------------------------------------+
セット内の 1 行 (0.00 秒)

rsadmin@'%' の権限を表示します。
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| rsadmin@% への権限付与 |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT オプション付きで、SELECT、RELOAD、SHUTDOWN、PROCESS、FILE、SUPER、EXECUTE、REPLICATION SLAVE、REPLICATION CLIENT、*.* の USER の作成を `rsadmin`@`%` に許可します |
| GRANT オプション付きで、*.* の BACKUP_ADMIN、CLONE_ADMIN、PERSIST_RO_VARIABLES_ADMIN、SYSTEM_VARIABLES_ADMIN を `rsadmin`@`%` に付与します |
| GRANT オプション付きで、`mysql`.* に対する INSERT、UPDATE、DELETE 権限を `rsadmin`@`%` に付与します |
| GRANT オプション付きで、`mysql_innodb_cluster_metadata`.* に対して INSERT、UPDATE、DELETE、CREATE、DROP、REFERENCES、INDEX、ALTER、CREATE TEMPORARY TABLES、LOCK TABLES、EXECUTE、CREATE VIEW、SHOW VIEW、CREATE ROUTINE、ALTER ROUTINE、EVENT、TRIGGER の権限を `rsadmin`@`%` に付与します |
| GRANT オプション付きで、`mysql_innodb_cluster_metadata_bkp`.* に対して INSERT、UPDATE、DELETE、CREATE、DROP、REFERENCES、INDEX、ALTER、CREATE TEMPORARY TABLES、LOCK TABLES、EXECUTE、CREATE VIEW、SHOW VIEW、CREATE ROUTINE、ALTER ROUTINE、EVENT、TRIGGER の権限を `rsadmin`@`%` に付与します |
| GRANT オプション付きで、`mysql_innodb_cluster_metadata_previous`.* に対して INSERT、UPDATE、DELETE、CREATE、DROP、REFERENCES、INDEX、ALTER、CREATE TEMPORARY TABLES、LOCK TABLES、EXECUTE、CREATE VIEW、SHOW VIEW、CREATE ROUTINE、ALTER ROUTINE、EVENT、TRIGGER の権限を `rsadmin`@`%` に付与します |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
セット内の 6 行 (0.00 秒)

参加するレプリカ セット インスタンスが現在接続されているインスタンスである場合は、より単純な構文を使用することもできます。

dba.configureReplicaSetInstance('',{clusterAdmin:"'rsadmin'@'%'"})

2. 次のように、dba.createReplicaSet コマンドを使用してレプリカ セットを作成し、結果を変数に保存します。

MySQL 192.168.1.10:5607 ssl JS > var rs = dba.createReplicaSet("yeyz_test")
インスタンス '192.168.1.10:5607' を持つ新しいレプリカセットが作成されます。

* 192.168.1.10:5607 の MySQL インスタンスをチェックしています

このインスタンスは自身のアドレスを192.168.1.10:5607として報告します。
192.168.1.10:5607: インスタンス構成は適切です。

* メタデータを更新しています...

192.168.1.10:5607 の ReplicaSet オブジェクトが正常に作成されました。
rs.addInstance() を使用して、このレプリカセットに非同期的に複製されたインスタンスを追加し、rs.status() を使用してそのステータスを確認します。

ご覧のとおり、yeyz_test のレプリカ セットを作成し、結果を変数 rs に保存しました。

3. rs.status()を使用して現在のレプリカセットメンバーを表示します。

MySQL 192.168.1.10:5607 ssl JS > rs.status()
{
    「レプリカセット」: {
        "名前": "yeyz_test",
        "プライマリ": "192.168.1.10:5607",
        「ステータス」: 「利用可能」
        "statusText": "すべてのインスタンスが利用可能です。",
        「トポロジー」: {
            "192.168.1.10:5607": {
                "アドレス": "192.168.1.10:5607",
                "instanceRole": "プライマリ",
                "モード": "R/W",
                「ステータス」: 「オンライン」
            }
        },
        「タイプ」: 「非同期」
    }
}

ここで、現在の ReplicaSet にはすでにインスタンス 192.168.1.10:5607 があり、そのステータスは使用可能であり、そのロールはプライマリであることがわかります。

4. ここで、rs.addInstance コマンドを使用して 2 番目のノードを追加し、rs.status を使用してステータスを確認します。

ここで注目すべきは、2 番目のノードを追加するときにデータ同期プロセスがあり、このデータ同期には 2 つの戦略があるということです。

戦略1: 完全回復

MySQL Clone コンポーネントを使用し、クローン スナップショットを使用して新しいインスタンス上のすべてのデータを上書きします。この方法は、Innodb レプリカ セットに空のインスタンスを追加するのに非常に適しています。

戦略2: 段階的な回復

MySQL のレプリケーション機能を利用して、失われたすべてのトランザクションを新しいインスタンスにコピーします。新しいインスタンスにトランザクションがほとんどない場合は、このプロセスは迅速です。この方法では、欠落したトランザクションのバイナリログを保存するインスタンスがクラスター内に少なくとも 1 つ存在する必要があります。欠落したトランザクションのバイナリログがクリアされている場合、この方法は使用できません。

インスタンスがクラスターに参加すると、MySQL Shell は、人間の介入なしに、適切な戦略を選択してデータを同期しようとします。同期方法を安全​​に選択できない場合は、クローンまたは増分同期を通じてデータを同期するオプションが DBA に提供されます。

次の例では、増分同期方法を自動的に選択してデータが同期されます。

MySQL 192.168.1.10:5607 ssl JS > rs.addInstance("192.168.1.20:5607")
警告: 必要な MySQL ロック サービス UDF をインスタンス '10.41.28.127:5607' にインストールできなかったため、ReplicaSet 操作の同時実行はサポートされていません。
いくつかの操作を同時に実行できるようにするには、MySQL ロック サービス プラグインがすべてのインスタンスで使用可能であることを確認してください。同時実行のサポートがなくても、操作は続行されます。

レプリカセットにインスタンスを追加しています...

* 検証チェックの実行

このインスタンスは自身のアドレスを192.168.1.20:5607として報告します。
192.168.1.20:5607: インスタンス構成は適切です。

* 非同期レプリケーション トポロジを確認しています...

* インスタンスのトランザクション状態を確認しています...
新しいインスタンスをプロビジョニングする最も安全で便利な方法は、自動クローン プロビジョニングを使用することです。これにより、既存のレプリカセット メンバーの物理スナップショットで '192.168.1.20:5607' の状態が完全に上書きされます。この方法をデフォルトで使用するには、'recoveryMethod' オプションを 'clone' に設定します。

警告: レプリカセットで実行されたすべての更新が GTID を有効にして実行され、パージされたトランザクションがなく、新しいインスタンスにレプリカセットまたはそのサブセットと同じ GTID セットが含まれていることが確実な場合は、レプリケーションに依存して新しいインスタンスの状態を段階的に回復しても安全です。この方法をデフォルトで使用するには、「recoveryMethod」オプションを「incremental」に設定します。

安全に使用できると思われるため、増分状態回復が選択されました。

* トポロジの更新
** 192.168.1.10:5607 から複製するように 192.168.1.20:5607 を構成する
** 新しいインスタンスが PRIMARY と同期するのを待機しています...

インスタンス '192.168.1.20:5607' がレプリカセットに追加され、192.168.1.20:5607 からレプリケートされています。

MySQL 192.168.1.10:5607 ssl JS >
MySQL 192.168.1.10:5607 ssl JS > rs.status()
{
    「レプリカセット」: {
        "名前": "yeyz_test",
        "プライマリ": "192.168.1.10:5607",
        「ステータス」: 「利用可能」
        "statusText": "すべてのインスタンスが利用可能です。",
        「トポロジー」: {
            "192.168.1.10:5607": {
                "アドレス": "192.168.1.10:5607",
                "instanceRole": "プライマリ",
                "モード": "R/W",
                「ステータス」: 「オンライン」
            },
            "192.168.1.20:5607": {
                "アドレス": "192.168.1.20:5607",
                "instanceRole": "セカンダリ",
                "モード": "R/O",
                「レプリケーション」: {
                    "applierStatus": "APPLIED_ALL",
                    "applierThreadState": "スレーブはすべてのリレー ログを読み取りました。さらに更新を待機しています",
                    "レシーバーステータス": "オン",
                    "receiverThreadState": "マスターがイベントを送信するのを待機しています",
                    「レプリケーションラグ」: null
                },
                「ステータス」: 「オンライン」
            }
        },
        「タイプ」: 「非同期」
    }
}

2番目のノードを追加した後、rs.statusを再度使用してレプリカセットの構造を表示すると、新しく追加された192.168.1.20:5607であるセカンダリノードが表示されていることがわかります。

もちろん、より詳細な出力を表示するには、次のコマンドを使用できます。

rs.ステータス({拡張:0})

rs.ステータス({拡張:1})

rs.ステータス({拡張:2})

レベルによって表示される情報が異なります。レベルが高いほど、より詳細な情報が表示されます。

ここでちょっとしたバグについて触れなければなりません。公式ドキュメントでは次のように書くことを推奨しています。

レプリカセット.ステータス(拡張=1)

原文は次のとおりです。

ReplicaSet.status(extended=1) の出力は Cluster.status(extended=1) と非常に似ていますが、主な違いは、InnoDB Cluster が増分リカバリ中に使用するのとは異なり、InnoDB ReplicaSet は常に MySQL レプリケーションに依存しているため、レプリケーション フィールドが常に使用可能であることです。フィールドの詳細については、「Cluster.status() を使用したクラスターのステータスの確認」を参照してください。

ただし、実際の操作では、この書き込み方法では次のようにエラーが報告されます。

MySQL 192.168.1.10:5607 ssl JS > sh.status(拡張=1)
レプリカセット「yeyz_test」のメンバーに接続されています。
ReplicaSet.status: 引数 #1 はマップである必要があります (ArgumentError)

バグかどうかは分かりません。

5. レプリカ セットを構築した後、プライマリ ノードのメタ情報ライブラリ テーブルを確認し、プライマリにデータを書き込んで、データが同期できるかどうかを確認します。

[(なし)] 17:41:10>データベースを表示;
+---------------------------------+
| データベース |
+---------------------------------+
| 情報スキーマ |
|mysql |
|mysql_innodb_cluster_メタデータ|
| パフォーマンススキーマ |
|システム|
| ようこそ
+---------------------------------+
セット内の6行(0.01秒)

[(なし)] 17:41:29>mysql_innodb_cluster_metadataを使用する
データベースが変更されました
[mysql_innodb_cluster_metadata] 17:45:12>テーブルを表示;
+-----------------------------------------+
| mysql_innodb_cluster_metadata 内のテーブル |
+-----------------------------------------+
| 非同期クラスターメンバー |
| 非同期クラスタービュー |
| クラスター |
| インスタンス |
| ルーターレストアカウント |
| ルーター |
| スキーマバージョン |
| v2_ar_clusters |
| v2_ar_メンバー |
| v2_クラスター |
| v2_gr_clusters |
| v2_インスタンス |
| v2_router_rest_accounts |
| v2_ルーター |
| v2_このインスタンス |
+-----------------------------------------+
セット内の行数は 15 です (0.00 秒)

[mysql_innodb_cluster_metadata] 17:45:45>ルーターから*を選択します。
空のセット (0.00 秒)

[(なし)] 17:45:52>データベースyeyazhouを作成します。
クエリは正常、1 行が影響を受けました (0.00 秒)

ご覧のとおり、プライマリ ノードにはメタ情報データベース mysql_innodb_cluster_metadata があり、ここに元の情報が保存されています。ルーター テーブルを確認したところ、MySQL ルーターを構成していなかったため、データがないことがわかりました。 MySQL Router の設定プロセスについては、次の記事で説明します。

プライマリ ノードに yeyazhou という名前のデータベースを作成すると、対応するデータベースがスレーブ ノードにも表示されます。

192.168.1.20 [(なし)] 17:41:41>データベースを表示;
+---------------------------------+
| データベース |
+---------------------------------+
| 情報スキーマ |
|mysql |
|mysql_innodb_cluster_メタデータ|
| パフォーマンススキーマ |
|システム|
| イエヤチョウ |
| ようこそ
+---------------------------------+
セット内の行数は 7 です (0.00 秒)

これは、レプリカ セットのレプリケーション関係が正しいことを示します。

この時点で、MySQL Shell を MySQL インスタンスに接続し、ReplicatSet を作成するプロセス全体が完了します。

次の記事では、MySQL Router を設定するプロセスと、MySQL Router を使用して基盤となるデータベースにアクセスする方法について説明します。

以上がMySQL Shellの紹介とインストールの詳細です。MySQL Shellの詳細については、123WORDPRESS.COMの他の関連記事にも注目してください。

以下もご興味があるかもしれません:
  • MySQL マスター/スレーブ ステータスを監視するシェル スクリプト
  • シェル スクリプトを使用してワンクリックで MySQL 5.7.29 をインストールする方法
  • MySQLの一般的なバックアップコマンドとシェルバックアップスクリプトの共有
  • MySQL データベースのデータを定期的にバックアップし、指定した期間保持するシェル スクリプト
  • シェル スクリプトは、仮想マシンの基本構成の作成を自動化します: tomcat--mysql--jdk--maven
  • MySQL のスケジュールされたバックアップ、削除、および回復機能を実装するシェル スクリプト
  • 各Mysqlテーブルの行数を正確にカウントする小さなシェルスクリプト
  • シェルスクリプトを使用して、サーバー上にMySQLデータベースアカウントを一括作成します。
  • シェルスクリプトを使用してMySQLにインデックスを追加する方法
  • このようなシェル スクリプトを使用して、多数の MySQL データベースを強制終了します (推奨)
  • シェル スクリプトを使用して複数の MySQL データベースを毎日自動的にバックアップする方法

<<:  ドラッグアンドドロップによる並べ替えの詳細を実現する js

>>:  純粋なCSSを使用してスイッチ効果を実現する

推薦する

ノードを使用して静的ファイルキャッシュを実装する方法

目次キャッシュキャッシュ位置の分類キャッシュ設定ヘッダーNodeは静的ファイルキャッシュを実装する強...

HTMLでカメラを読み込む方法

効果図: 全体的な効果: ビデオ読み込み中: 写真:ステップ1: HTML要素を作成するまず、HTM...

MySQLの論理アーキテクチャに関する深い理解

MySQL は現在、ほとんどの企業や事業体で使用されているデータベースです。MySQL が使用される...

Mysql テーブルで利用可能な最小 ID 値を照会する方法

今日、研究室のプロジェクトを見ていたとき、私にとって「難しい」問題に遭遇しました。実は、それは私があ...

Windows Server 2016 リモート デスクトップ サービスを展開するためのクイック スタート ガイド

現在、2016サーバーは、win2008や2012よりも優れたマルチサイトhttpsサービスをサポー...

Vueはコードのハイライトを実現するためにモナコを使用しています

Vue 言語と要素コンポーネントを使用して、コード コンテンツの入力を必要とし、ハイライト表示が可能...

枠線や境界線のない iframe を使用するための完全ガイド (実践経験のまとめ)

<iframe src=”ページのURL” width=”100″ height=”30″ f...

MySQL複合クエリの詳細な説明

UNIONの使用ほとんどの SQL クエリは、1 つ以上のテーブルからデータを返す単一の SELEC...

Vueフィルターの詳細な説明

<本文> <div id="ルート"> <h2&...

ウェブサイトのコンテンツの100~1%はナビゲーションである

ウェブサイトでは、コンテンツの(100-1)%がナビゲーションです1. ジェシー・ジェームズ・ギャレ...

ネイティブJSは非常に見栄えの良いカウンターを実装します

今日は、ネイティブ JS で実装された見栄えの良いカウンターを紹介します。効果は次のとおりです。 以...

HTMLフロートの使用法の簡単な分析

float の使用例左サスペンション: float:left;右サスペンション: float:rig...

MySQL DEFINER の使用方法の詳細な説明

目次序文: 1.DEFINERの簡単な紹介2. いくつかの注意点要約:序文: MySQL データベー...

JavaScript マウスイベントのケーススタディ

マウスイベントマウスが特定の操作を実行すると、イベント オブジェクトが生成され、イベントがトリガーさ...

JavaScriptは検証コードと検証のランダム生成を実装します

この記事では、検証コードのランダム生成と検証を実現するためのJavaScriptの具体的なコードを参...