Du er formentlig bekendt med de to formater for binær logning , sætningsbaseret -- som logger de faktiske forespørgsler, der ændrer data på masteren, så de kan udføres på slaven, og rækkebaserede -- som logger før- og/eller efterbilleder af de faktiske rækkedata, der var ændret af forespørgslen, så slaven direkte kan anvende disse ændringer på sine data... og mixed-mode, hvor optimizeren og lagermotoren bestemmer, hvilket format der er det optimale format på en forespørgsel-for-forespørgsel-basis.
Den erklæring, du udfører, er i princippet usikker fordi du bruger INSERT ... SELECT ind i en tabel med en automatisk stigningskolonne. Hvis en forespørgsel af den generelle form blev brugt i en STATEMENT -baseret miljø og SELECT ikke returnerede rækkerne i samme rækkefølge på master og slave, kunne rækkerne vælges i en anden rækkefølge, og dermed ende med forskellige auto-increment værdier.
I praksis er den specifikke forespørgsel du udfører er deterministisk, fordi du kun indsætter én række, og du udtrykkeligt angiver værdien for automatisk stigning. Jeg formoder, at det er årsagen til din forvirring. Det ser dog ud til, at du stadig udløser advarslen, fordi du gør INSERT ... SELECT ind i en tabel med en automatisk stigning, og serveren ser ud til at anvende den generaliserede "usikre" bestemmelse på forespørgslen som et principspørgsmål snarere end præcision.
Skift dit binlog_format til MIXED bør få advarslen til at forsvinde, da serveren kan skifte tilstand efter eget skøn... og det er meget usandsynligt, at den har negative bivirkninger. Hvis det ikke var for det faktum, at STATEMENT har altid været standarden (da det oprindeligt var den eneste tilgængelige form for replikering), formoder jeg, at de ville have lavet MIXED standarden for længe siden... faktisk, hvis du gør dig bekendt med det interne i binære logfiler, ville du sandsynligvis være tilbøjelig til at gøre som jeg og bruge ROW på næsten alt... det har en tendens til at skabe en meget mere nyttig binær log til fejlfinding og til at bakke dig selv ud af problemer, fordi de "gamle" rækkedata er logget på DELETE og UPDATE .