Pravděpodobně znáte dva formáty binárního protokolování na základě příkazů – který zaznamenává skutečné dotazy, které upravují data na hlavním serveru tak, aby je bylo možné provést na podřízeném zařízení, a na základě řádků – který zaznamenává obrazy před a/nebo po skutečných datech řádku, která byla změněno dotazem, takže slave může přímo aplikovat tyto změny na svá data... a smíšený režim, kde optimalizátor a úložiště určují, který formát je optimální, na základě dotazu po dotazu.
Prohlášení, které provádíte, je v zásadě nebezpečné protože používáte INSERT ... SELECT do tabulky se sloupcem s automatickým přírůstkem. Pokud je dotaz tohoto obecného formuláře byly použity v STATEMENT -based prostředí a SELECT nevrátila řádky ve stejném pořadí na master a slave, mohly být řádky vybrány v jiném pořadí, a tak skončit s různými hodnotami automatického zvýšení.
V praxi konkrétní dotaz, který provádíte je deterministický, protože vkládáte pouze jeden řádek a explicitně určujete hodnotu automatického přírůstku. Mám podezření, že to je příčina vašeho zmatku. Zdá se však, že stále spouštíte varování, protože provádíte INSERT ... SELECT do tabulky s automatickým přírůstkem a zdá se, že server aplikuje zobecněné "nebezpečné" určení na dotaz spíše z principu než z přesnosti.
Přepínání binlog_format na MIXED by mělo varování zmizet, protože server může přepínat režimy podle svého uvážení... a je velmi nepravděpodobné, že bude mít negativní vedlejší účinky. Nebýt toho, že STATEMENT byl vždy výchozí (protože zpočátku to byl jediný dostupný druh replikace), mám podezření, že by udělali MIXED výchozí nastavení již dávno... ve skutečnosti, pokud se seznámíte s vnitřními prvky binárních protokolů, pravděpodobně budete chtít udělat to, co já, a použít ROW téměř na všechno... má tendenci vytvářet mnohem užitečnější binární protokol pro odstraňování problémů a ochranu před problémy, protože „stará“ data řádku se zaznamenávají na DELETE a UPDATE .