8.0にアップグレードする
- データベース構成ファイルをバックアップする
cd /etc
cp my.cnf my.cnf.back
- データベースに接続しているアプリケーションを停止し、データベースのバックアップを実行します（バックアップが必要なデータがある場合）
2.1. データベースをバックアップします (3 つから 1 つを選択し、使用しません)
データベースをバックアップするディレクトリ mkdir /home/hd/package/mysqlback を作成し
、インスタンス上のすべてのデータベースをバックアップします。
mysqldump -u root -p --all-databases > /home/user/package/mysqlback/all_db.sql
2.2. データディレクトリ全体をバックアップする(3から1を選択、要操作)
mysql データ ディレクトリ (my.cnf の datadir) を入力します。 cd /var/lib/
バックアップ データ ディレクトリ tar -czvf mysql.tar.gz mysql
解凍ディレクトリ (現在は使用されていません) tar -xzvf mysql.tar.gz
2.3. データベース全体をバックアップする（3つから1つを選択、要操作）
ディレクトリを入力します cd /usr/share/
バックアップ ディレクトリ tar -czvf mysql-8.0.tar.gz mysql-8.0
解凍ディレクトリ (現在は使用されていません) tar -xzvf mysql-8.0.tar.gz
- データベースサービスを停止し、元のデータベースをアンインストールします。
service mysqld stop
rpm -qa|grep -i mysql 古いデータベースを表示します
mysql-community-client-8.0.16-2.el7.x86_64
mysql-community-libs-8.0.16-2.el7.x86_64
mysql-community-server -8.0.16-2.el7.x86_64
mysql-community-common-8.0.16-2.el7.x86_64
mysql-community-libs-compat-8.0.16-2.el7.x86_64
データベースを削除します。順序要件があります。 (共通 > ライブラリ > クライアント > サーバー)
rpm -e --nodeps mysql-community-common-8.0.16-2.el7.x86_64
rpm -e --nodeps mysql-community-libs-8.0.16-2.el7。 x86_64
rpm -e --nodeps mysql-community-libs-compat-8.0.16-2.el7.x86_64
rpm -e --nodeps mysql-community-client-8.0.16-2.el7.x86_64
rpm -e -- nodeps mysql -community-server-8.0.16-2.el7.x86_64
警告: /etc/my.cnf は /etc/my.cnf.rpmsave として保存されました
- 最新のデータベースをインストールする
ディレクトリに入ります cd ~
ディレクトリを作成します mkdir mysql
decompress tar xvf mysql-8.0.22-1.el7.x86_64.rpm-bundle.tar -C ./mysql
Installation cd mysql
sudo yum install mysql-community-{server, client, common, libs}-* --exclude=' minimum '
cd ...
設定ファイルを変更し、my.cnf.back の設定を my.cnf
cd /etc
mv my.cnf my.cnf.back2
mv my にコピーします。 cnf.back my .cnf
start mysql サービス
sudo サービス mysqld start
mysql -V
データバックアップ：
バージョン 8.0.16 は分岐点であり、それ以降のバージョンは 1 つのステップで解決できます。1. my.cnf の一貫性を維持するために、
実行中の 8.0.20 を停止し、8.0.22 圧縮パッケージを解凍し、新しい 8.0.22 を指す古いソフト リンクを削除します。2. 次に、bin ディレクトリに入ります。datadir は既存のデータ ディレクトリmysqld_safe --user=mysql --datadir=/path/to/existing-datadir & 3. 停止して再起動します。
マスタースレーブ構造
なぜマスター/スレーブレプリケーションが必要なのでしょうか
? データのホットバックアップを実行します。
●マスターデータベースがダウンした場合でも、業務システムをスレーブデータベースに素早く切り替えることができ、データ損失を回避します。
●業務量がますます大規模化し、I/Oアクセス頻度が高くなり、1台のマシンでは対応できなくなるため、複数のデータベースをストレージとして利用し、ディスクI/Oアクセス頻度を低減しています。単一マシンの I/O パフォーマンスを向上させます。データベースへの読み取りと書き込みの両方が同じデータベース サーバー上で実行されると、業務システムのパフォーマンスが低下します。
●複雑な業務を伴うシステムでは、SQL文にテーブルロックが必要となり、一時的に読み取りサービスが利用できなくなり、業務運営に大きな影響を与えるケースがあります。書き込みを担当し、スレーブデータベースが書き込みを担当し、ライブラリが読み取りを担当することで、メインライブラリがテーブルをロックしても、スレーブライブラリからの読み込みにより業務の正常な動作が保証されます。マスター/スレーブ レプリケーション (読み取り/書き込み分離) を実行することで、プライマリ データベースの負荷を軽減します。
マスター/スレーブ レプリケーション プロセス:
(1) まず、トランザクションがコミットされると、MySQL メイン データベースはデータ変更をバイナリ ログ ファイル Binlog にイベントとして記録します。MySQL メイン データベースの sync_binlog パラメータは、Binlog ログがディスクにフラッシュされるように制御します。 。
(2) メインライブラリは、バイナリログファイル Binlog 内のイベントをスレーブライブラリのリレーログ Relay Log にプッシュし、スレーブライブラリはリレーログ Relay Log に基づいてデータ変更操作をやり直し、メインライブラリとスレーブに到達します。論理レプリケーションによるライブラリ データの一貫性。
MySQL は 3 つのスレッドを使用してマスター データベースとスレーブ データベース間のデータ レプリケーションを完了します: スレーブ データベースで
レプリケーションが開始されると、マスター データベースに接続するための I/O プロセスが最初に作成されます。次にマスター データベースは、読み取るための Binlog Dump スレッドを作成します。データベース イベントを作成し、I/O に送信します。O スレッドと IO スレッドはイベント データを取得し、スレーブ ライブラリのリレー ログ リレー ログに更新します。その後、スレーブ ライブラリの SQL スレッドは、リレー内の更新されたデータベース イベントを読み取ります。 RelayLog をログに記録し、適用します。
1 つのマスターと 1 つのスレーブ
1つのマスターノードと1つのスレーブノード、シンプルで便利
デュアルマスター構造：「相互マスター・スレーブ」
●簡単な問題: データの不整合があるため、慎重に使用してください
●考慮すべき点: ID の自動増加
解決策: UUID を変更して、
mysql を通じて uuid を生成します。これは後で変更に使用されます。
select uuid()
生成的uuid
c3e68eed-8e40-11eb-9d18-fefcfee28c83
uuid
vim /mysql/data/auto.cnfを 236 に変更します
server-uuid=c3e68eed-8e40-11eb-9d18-fefcfee28c83
1 人のマスター、多数のスレーブ
「スレーブライブラリから読み出しを行う」ため、「システムの読み出し性能の拡張」によく使われます。
複数のマスターと 1 つのスレーブ
MySQL バージョン 5.7 以降サポートされており、「マルチソース レプリケーション」とも呼ばれ、データ フローの方向は、複数のマスター データベースからスレーブ データベースにデータを同期することです。主に次の用途で使用されます
。
スレーブデータベース データの統計分析に便利です。
読み取りと書き込みが分離され、スレーブ データベースはクエリにのみ使用されるため、データベース全体のパフォーマンスが向上します。
カスケードレプリケーション
マスター/スレーブ レプリケーションに基づいて、マスターとスレーブの間にカスケード レプリケーション スレーブ サーバーがあり、カスケード レプリケーション ホストがマスター サーバーのデータをコピーする場合、カスケード レプリケーション ホストがマスター サーバーとして機能し、スレーブ サーバーがレプリケーションを実行します。カスケード レプリケーションのホスト データとバイナリ ログ データ」。
中間カスケード レプリケーション ホストはバイナリ ログを他のスレーブ サーバーに転送できないため、log_slave_updates オプションを追加する必要があります。「マスター サーバーのバイナリ ログ ファイルをスレーブ サーバーに書き込むことが目的です。」
