L'instruction que vous exécutez n'est pas sûre en principe parce que vous utilisez INSERT ... SELECT dans un tableau avec une colonne auto-incrémentée. Si une requête de cette forme générale ont été utilisés dans un STATEMENT - et l'environnement SELECT n'a pas renvoyé les lignes dans le même ordre sur le maître et l'esclave, les lignes peuvent être sélectionnées dans un ordre différent et se retrouver ainsi avec des valeurs d'auto-incrémentation différentes.
En pratique, le spécifique la requête que vous exécutez est déterministe car vous n'insérez qu'une seule ligne et vous spécifiez explicitement la valeur d'auto-incrémentation. Je soupçonne que c'est la cause de votre confusion. Cependant, il semble que vous déclenchez toujours l'avertissement car vous faites INSERT ... SELECT dans une table avec une auto-incrémentation, et le serveur semble appliquer la détermination "non sécurisée" généralisée à la requête par principe, plutôt que par précision.
Changer votre binlog_format à MIXED devrait faire disparaître l'avertissement, car le serveur peut changer de mode à sa discrétion... et il est très peu probable qu'il ait des effets secondaires négatifs. S'il n'y avait pas le fait que STATEMENT a toujours été la valeur par défaut (puisque initialement c'était le seul type de réplication disponible), je soupçonne qu'ils auraient fait MIXED la valeur par défaut il y a longtemps... en fait, si vous vous familiarisez avec les rouages des journaux binaires, vous seriez probablement enclin à faire comme moi et à utiliser ROW sur à peu près tout ... cela a tendance à créer un journal binaire beaucoup plus utile pour le dépannage et vous sortir du pétrin, car les "anciennes" données de ligne sont enregistrées sur DELETE et UPDATE .
