Du är förmodligen bekant med två format för binär loggning , satsbaserad -- som loggar de faktiska frågorna som modifierar data på mastern så att de kan köras på slaven, och radbaserad -- som loggar före- och/eller efterbilder av den faktiska raddata som var ändras av frågan, så att slaven direkt kan tillämpa dessa ändringar på sina data... och blandat läge, där optimeraren och lagringsmotorn bestämmer vilket format som är det optimala formatet på en fråga-för-fråga-basis.
Uttrycket du kör är i princip osäkert eftersom du använder INSERT ... SELECT i en tabell med en kolumn för automatisk ökning. Om en fråga av den allmänna formen användes i ett STATEMENT -baserad miljö och SELECT inte returnerade raderna i samma ordning på master och slav kunde raderna väljas i en annan ordning, och därmed sluta med olika auto-inkrementvärden.
I praktiken är den specifika fråga du kör är deterministisk eftersom du bara infogar en rad och du explicit anger värdet för automatisk ökning. Jag misstänker att det är orsaken till din förvirring. Det verkar dock som att du fortfarande utlöser varningen eftersom du gör INSERT ... SELECT in i en tabell med en automatisk ökning, och servern verkar tillämpa den generaliserade "osäkra" beslutsamheten på frågan som en principfråga snarare än precision.
Byt binlog_format till MIXED bör göra att varningen försvinner, eftersom servern kan byta läge efter eget gottfinnande... och det är mycket osannolikt att det har negativa biverkningar. Om det inte vore för det faktum att STATEMENT har alltid varit standard (eftersom det till en början var den enda tillgängliga typen av replikering), misstänker jag att de skulle ha gjort MIXED standarden för länge sedan... faktiskt, om du bekantar dig med det interna i binära loggar, skulle du förmodligen vara benägen att göra som jag och använda ROW på nästan allt... det tenderar att skapa en mycket mer användbar binär logg för att felsöka och rädda dig själv ur problem, eftersom den "gamla" raddatan är inloggad DELETE och UPDATE .