著者: shuixian
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 キーワードを使用してワークスペースが実行されます。