0

現在、STATEMENT bin ログ形式が正常に機能するデータベースがあります。
ここで、自動インクリメント値を持つ新しいテーブルを追加しています。
この自動インクリメント列は、ビジネス ロジックの目的ではありません。
これを主キーの一部として追加しました。
ここで offer_expiry_time は主キーの最初の部分です。これは、有効期限の時間範囲に基づく範囲クエリとしてすべてのクエリがあるためです。

テーブルが次のようになっているとします。

CREATE TABLE offer_expiry_info  
    offer_expiry_time BIGINT UNSIGNED NOT NULL null,  
    purchase_id INT UNSIGNED auto_increment,
    PRIMARY KEY (offer_expiry_time, purchase_id),
    キー idx_purchase_id (purchase_id)
)エンジン=INNOBB;

今、私たちの懸念は次のとおりです。

  1. STATEMENT レベルの bin ログ形式は、このテーブルで機能しますか? (レプリケーション全体で自動インクリメント列の値が異なっていても問題ありません)。基本的に STATEMENT レベルは機能しますか?

  2. 機能する場合、障害のある db マシンを起動する際に発生する可能性がある問題は何ですか?

  3. STATEMENT モードが機能しない場合、このテーブルだけに特定の (MIXED) レプリケーション モードを使用できますか? 同じデータベース内の残りのテーブルを STATEMENT モードにすることはできますか?

  4. mysql がレプリケーションを処理する方法を知らないので、これは非常にばかげた質問かもしれません。クエリの種類に基づいてレプリケーション モードを指定することはできますか? (挿入クエリの場合は ROW レベルのレプリケーションを実行し、DELETE クエリの場合は STATEMENT レベルのレプリケーションを実行します)

    質問 4 は、範囲ベースの削除に基づいて削除を実行するため、削除クエリに STATEMENT レプリケーションを使用できる場合、パフォーマンスが向上するためです。

DELETE FROM order_expiry_info WHERE offer_expiry_time "LESS THAN" SOME TIME

バッチ挿入を行うため、STATEMENT レベルのレプリケーションは非常に役立ちます。
自動インクリメント列を持つテーブルに STATEMENT レベルの bin ログ形式を持たせることは可能ですか?

[編集済み] また、トランザクションの分離レベルに関して別の問題があります。
エラー: 「エラー Binary logging not possible を取得しています。メッセージ: InnoDB のトランザクション レベル 'REA D-UNCOMMITTED' は、binlog モード 'STATEMENT' に対して安全ではありません」

どんな提案も非常に役に立ちますか?

4

1 に答える 1

1

はい、これらのシナリオはステートメントバイナリログでうまく機能します。

ログにアクセスできる場合は、各ステートメントの前に特定の値がログに記録され、タイムスタンプや自動インクリメント値などが適切に保持されるようになっていることがわかります。

私は何年もステートメントベースのレプリケーションを使用してきましたが、これらの領域のいずれにおいても問題はありませんでした。これに固執し、特定のパフォーマンス状況が発生した場合にのみ、行ベースまたは混合レプリケーションを検討することをお勧めします。

ステートメントベースのレプリケーションでは安全ではない特定のタイプの使用法があることに注意してください。ただし、単純な自動インクリメントの使用法はそれらの 1 つではありません。

于 2012-10-02T06:24:38.083 に答える