これを修正するには2つの方法があります：
-
MySQLコンソールで以下を実行します。
SET GLOBAL log_bin_trust_function_creators = 1; -
mysql.ini構成ファイルに以下を追加します。
log_bin_trust_function_creators = 1;
この設定により、非決定論的関数のチェックが緩和されます。非決定論的関数は、データを変更する関数です（つまり、ステートメントを更新、挿入、または削除します）。詳細については、こちら を参照してください。 。
バイナリロギングが有効になっていない場合、この設定は適用されないことに注意してください。
log_bin_trust_function_creators
最善のアプローチは、格納された関数の決定論的宣言をよりよく理解して使用することです。これらの宣言は、レプリケーションを最適化するためにMySQLによって使用されます。正常なレプリケーションを実現するには、これらの宣言を慎重に選択することをお勧めします。
決定的 ルーチンは、同じ入力パラメーターに対して常に同じ結果を生成し、それ以外の場合は決定的ではない場合、「決定論的」と見なされます。これは主に文字列または数学処理で使用されますが、それに限定されません。
決定的ではない 「DETERMINISTIC」の反対です。"ルーチン定義でDETERMINISTICもNOTDETERMINISTICも指定されていない場合、デフォルトはNOT DETERMINISTICです。関数が決定論的であることを宣言するには、DETERMINISTICを明示的に指定する必要があります。 "。したがって、ステートメントが作成されない場合、MySQlは関数を" NOT DETERMINISTIC "として処理するようです。マニュアルからのこのステートメントは、次のことを示す別のマニュアル領域からのステートメントと矛盾しています。"ストアド関数の場合、それが決定論的であるか、データを変更しないことを宣言する必要があります。そうしないと、データのリカバリまたはレプリケーションにとって安全でない可能性があります。デフォルトでは、CREATE FUNCTIONステートメントを受け入れるには、DETERMINISTIC、NO SQL、またはREADSSQLDATAの少なくとも1つを明示的に指定する必要があります。そうしないと、エラーが発生します "
宣言がない場合、MySQL 5.5で個人的にエラーが発生したため、他の宣言に関係なく、常に「DETERMINISTIC」、「NOT DETERMINISTIC」、「NO SQL」、または「READSSQLDATA」の宣言を少なくとも1つ配置します。
SQLデータを読み取ります これは、関数がデータベースからデータを読み取るだけであることをMySQLに明示的に通知します。したがって、データを変更する命令は含まれていませんが、データを読み取るSQL命令（SELECTなど）は含まれています。
SQLデータを変更 これは、ルーチンにデータを書き込む可能性のあるステートメントが含まれていることを示しています（たとえば、UPDATE、INSERT、DELETE、またはALTER命令が含まれています）。
SQLなし これは、ルーチンにSQLステートメントが含まれていないことを示しています。
SQLを含む これは、ルーチンにSQL命令が含まれているが、データの読み取りまたは書き込みを行うステートメントが含まれていないことを示しています。これらの特性のいずれも明示的に指定されていない場合、これがデフォルトです。このようなステートメントの例は、SELECT NOW（）、SELECT [email protected] です。 、SET @x =1またはDORELEASE_LOCK（'abc'）。これらは実行されますが、データの読み取りも書き込みもされません。
NOW（）、UUID（）など、決定論的に安全ではないMySQL関数があり、マシンごとに異なる結果を生成する可能性があるため、そのような命令を含むユーザー関数はNOTDETERMINISTICとして宣言する必要があることに注意してください。 。また、複製されていないスキーマからデータを読み取る関数は、明らかにNONDETERMINISTICです。*