shyikoコネクタを使用して、mysqlクラスタから下流のデータベースシステムへのbinログの変更をストリームします。リスニングMySQLのシステムは、何らかの理由でダウンした場合にはMySQL - タイムスタンプに基づいてbinログの位置を見つけよう
クラスタ= MySQLのマスター+プライマリスレーブ+セカンダリスレーブ
は、メカニズムは、マスターとしてスレーブを促進して、いつものように継続することです。しかし、問題はbinのログファイルであり、位置は、失敗したマシンと新しく昇格したスレーブmysqlとはまったく異なります。
両方のマシンのコミットログの間で考えることができる唯一の共通点はtimestampです。さらに、mysqlbinlogユーティリティには--start-datetimeオプションを使用してタイムスタンプを設定する機能があります。
特定のタイムスタンプを使用してmysql binログの位置を調べる方法はありますか?上記のライブラリは、タイムスタンプではなく特定の位置のみを使用できるためです。いいえの場合は、それを達成するためにどのように行かなければなりません。
「MySQLクラスタ」というフレーズは、説明しているものとは異なる製品を意味するので、おそらく削除する必要があります。 '--start-datetime'の実装は実際には非常に原始的です。ただそのタイムスタンプでレコードを見つけるまでログをスキャンします。明確にするために、あなたのマシンはA> B> Cを複製しています。リスニングからAに切り替えて、Aが失敗したためBを聞き始めます。 MySQL Serverのバージョンは何ですか? –
"My SQL cluster" - なぜクラスタがMySQLマスター+プライマリスレーブ+セカンダリスレーブであるかを述べました。私は現在5.5.21を使用しています(それは古いです)。しかし、アイデアはバージョンに関係なく共通です。 –
はい、もちろん、一般的な考え方は5.xでは共通ですが、それぞれのバージョンには追加機能があります。明白な解決策は、GTIDです。これは、機能を提供する主な価値提案の1つですが、5.6+が必要です。これはかなりの手間をかけて有効にすることができ、 "コネクタ"もサポートする必要があります。もう一つの理論的な回避策には、サーバ5.6.12以降に同梱されているmysqlbinlogのコピーが必要ですが、機能はサーバではなくクライアントにあり、クライアントは下位互換性があるため、5.1と古いサーバに対して実行すると動作します。 –