ホームページ  >  記事  >  データベース  >  MySQL ストアド プロシージャ、関数、トリガー、レプリケーション: FAQ

MySQL ストアド プロシージャ、関数、トリガー、レプリケーション: FAQ

高洛峰
高洛峰オリジナル
2016-12-02 14:50:091085ブラウズ

MySQL 5.1 ストアド プロシージャと関数はレプリケーションで動作しますか?
はい、標準の動作は、マスター MySQL サーバーからスレーブ サーバーに複製されるストアド プロシージャと関数に実装されます。いくつかの制限があります。詳細については、「ストア・サブルーチンおよびトリガー・バイナリ・ログ機能」で説明します。
マスターサーバーで作成されたストアドプロシージャと関数をスレーブサーバーにコピーできますか?
はい、一般的な DDL ステートメントを通じて実行されるストアド プロシージャと関数の場合、マスター サーバー上で作成されたものがスレーブ サーバーにコピーされるため、ターゲットは両方のサーバーに存在します。ストアド プロシージャと関数の ALTER ステートメントと DROP ステートメントもレプリケートされます。
コピーされたストアド プロシージャと関数ではどのような動作が発生しますか?
MySQL はストアド プロシージャと関数で発生するすべての DML イベントを記録し、これらの個々のアクションをスレーブ サーバーに複製します。ストアド プロシージャや関数への実際の呼び出しはコピーされません。
ストアド プロシージャ、関数、レプリケーションを一緒に使用する場合に特別なセキュリティ要件はありますか?
はい、スレーブにはマスターのバイナリ ログを読み取るステートメントを実行する権限があるため、レプリケーションで使用されるストアド プロシージャと関数には指定されたセキュリティ制約が存在します。一般にレプリケーションまたはバイナリ ログが (ポイントインタイム リカバリの目的で) 有効になっている場合、MySQL DBA は 2 つのセキュリティ オプションを利用できます:
ストアド プロシージャを作成したいユーザーには SUPER 権限が付与されている必要があります。
あるいは、DBA は log_bin_trust_routine_creators システム変数を 1 に設定することもできます。これにより、標準の CREATE ROUTINE 権限を持つユーザーがストアド プロシージャと関数を作成できるようになります。

ストアド プロシージャと関数をコピーする動作に対する制限は何ですか?
ストアド プロシージャに埋め込まれた不定 (ランダム) または時間ベースの行は、適切にコピーされません。ランダムに生成された結果は、その性質上、予測可能ですが、確実に複製することはできません。したがって、スレーブ サーバーに複製されるランダムな動作は、マスター サーバーで発生する動作を反映しません。ストアド プロシージャまたは関数 DETERMINISTIC を宣言するか、log_bin_trust_routine_creators でシステム変数を 0 に設定すると、ランダム値の操作を呼び出すことができることに注意してください。
さらに、時間ベースの動作はスレーブ サーバーでは再現できません。バイナリ ログには DML イベントのみが記録され、タイミングが含まれないため、このような時間ベースの動作は、レプリケーションに使用されるバイナリ ログを介してストアド プロシージャで再現できないためです。制約。
最後に、大規模な DML アクション (一括挿入など) 中に非対話型テーブルでエラーが発生した場合、非対話型テーブルでレプリケーションが実行され、マスター サーバーがレプリケートされた DML アクションから部分的に更新される可能性があります。非対話型テーブルのバージョン。しかし、エラーが発生したため、スレーブ サーバーは更新されませんでした。 関数の DML 動作では、マスター サーバーでエラーを引き起こす更新が無視され、エラーを引き起こさない更新がスレーブ サーバーにコピーされるように、IGNORE キーワードを使用してワークスペースが実行されます。

上記の制限は、MySQL のポイントインタイム リカバリを実行する機能に影響しますか?
レプリケーションに影響を与えるのと同じ制限が、ポイントインタイム リカバリにも影響します。
前述の制限を修正するには MySQL は何をすべきでしょうか?
MySQL の将来のリリースには、レプリケーションの処理方法を選択する機能が搭載される予定です:
ステートメントベースのレプリケーション (現在の実装)。
行レベルのレプリケーション (これにより、前述のすべての制限が解決されます)。
トリガーはレプリケーションで機能しますか?
MySQL 5.1 のトリガーとレプリケーションは、他のほとんどのデータベース エンジンと同様に機能し、トリガーを介してマスターで実行されたアクションはスレーブにレプリケートされません。代わりに、マスター MySQL サーバー上のテーブルにあるトリガーは、スレーブでもトリガーをアクティブにできるように、MySQL スレーブ上に存在するテーブル内に作成する必要があります。

マスターサーバーからスレーブサーバーにコピーされたトリガープログラムを通じてビヘイビアーを実行するにはどうすればよいですか?
まず、マスターサーバー上のトリガープログラムをスレーブサーバー上で再構築する必要があります。再構築されると、レプリケーション プロセスは、レプリケーションに関係する他の標準 DML ステートメントと同様に機能します。例: メイン MySQL サーバー上にある、トリガー AFTER が挿入された EMP テーブルを考えてみましょう。同じ EMP テーブルと AFTER 挿入トリガーがスレーブ サーバーにも存在します。コピー プロセスは次のようになります。
1. EMP の INSERT ステートメントを作成します。
2. EMP でトリガーがアクティブになった後。
3. INSERT ステートメントがバイナリ ログに書き込まれます。
4. スレーブサーバー上のレプリケーションは、EMP テーブルへの INSERT ステートメントを取得し、スレーブサーバー上で実行します。
5. スレーブサーバーEMPにあるAFTERトリガープログラムが起動されます。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。