web-dev-qa-db-ja.com

MySQLの以前のスレーブをマスターに変更し、スレーブステータス情報を削除する方法は？

マスターが失敗したマスター->スレーブ構成があります。私は古いスレーブをマスターに、古いマスターをスレーブにリセットすることができました。いいよ.

私ができていないように見えるのは、現在新しいマスターである古いスレーブのマスター情報を削除することです。そうですか：

mysql> show slave status \G
*************************** 1. row ***************************
           Slave_IO_State: 
              Master_Host: 10.1.2.101
              Master_User: replicationSlave
              Master_Port: 3306
              ...
              Slave_IO_Running: No
              Slave_SQL_Running: No

私は多くの MySQLドキュメント を読みましたが、まだ新しいマスターからスレーブ情報をクリアする方法を見つけていません。私はもう試した：

  1. RESET SLAVEは、これらの設定をクリアしていないようです。 [[実際には、master.infoファイルは削除されますが、メモリ設定は削除されません。下記参照。]]
  2. CHANGE MASTER TO MASTER_Host=''は、最近サポートが終了したため、エラーが発生しただけです。
  3. プログラムで追加されたため、マスター情報がないmy.cnfを確認しています。
  4. RESET MASTERいくつかのmysqlドキュメントで推奨されているため。これは、binログのみをリセットします。
  5. 内部のMySQLテーブルを調べて、クリアするフィールドが見つかるかどうかを確認します。

MySQL〜5.5.9でこれを行う適切な方法は何ですか？助けてくれてありがとう。

編集：

したがって、@ RolandoMySQLDBAが暗示するように、RESET SLAVEはmaster.infoファイルを削除することがわかります。ただし、スレーブ情報を削除する前に、サーバーを再起動する必要があります。

このスレーブ情報を削除する方法はありますかなし mysqldを再起動する必要がありますか？

mysqlreplicationmysql-5.5
10
Gray -- SO stop being evil

MySQL 5.5.16以降では、RESET SLAVE ALLを使用してRESET SLAVEが行うすべてのことを実行できますandメモリから接続パラメーターをリセットします。この方法では、 mysqldの再起動。

10
Filipe Giusti

MySQLインスタンスからスレーブ情報をクリアする最も速くて汚い方法

  • skip-slave-startを[mysqld]の下の/etc/my.cnfに追加します
  • service mysql stop
  • rm -f /var/lib/mysql/master.info /var/lib/mysql/relay-*
  • service mysql start
  • /etc/my.cnfからskip-slave-startを削除します

それでうまくいくはずです!!!

MySQLドキュメンテーションRESET SLAVE によると、これは必要です。

MySQL 5.5では（MySQL 5.1以前の場合とは異なり）、RESET SLAVEは、メモリーに保持されているマスターホスト、マスターポート、マスターユーザー、マスターパスワードなどのレプリケーション接続パラメーターを変更しません。これは、RESET SLAVEの後にCHANGE MASTER TOステートメントを必要とせずに、START SLAVEを発行できることを意味します。

したがって、レプリケーション情報はまだメモリ内にあります。 mysqlの再起動が唯一の方法です。

6
RolandoMySQLDBA

RESET SLAVEに続いて再起動しても、phpmyadminに関する限り、スレーブ情報は消去されません。 CHANGE MASTER TO MASTER_Host=''も設定する必要があります。

5
Jack

マスタースレーブデータの上書きを避けるために、「mysqld」の下の構成ファイル（「/etc/my.cnf」内）でskip-slave-startコマンドを維持することをお勧めします。例として、クラウド環境で作業しているときに、古いマスターがクラッシュし、プロバイダーが問題を修正したときに正常に再起動するとします。古いスレーブ（現在は新しいマスター）は古いマスターから複製し、以前のデータを上書きします。 DBAはこれを実現する機会があります。

ところで、これは非クラウド環境にも関係があります。たとえば、別の管理者が調整せずに古いマスターを起動したとします。また、スレーブであっても「skip-slave-start」コマンドを維持することをお勧めする別の問題–自動レプリケーションがないため、予期しない結果を防ぐための制御が強化されます。 :)

3
Lena Weber