Hello.
> Nope, all three were MyISAM.
>
> After I sorted out the issue with all of the session's statements
> becoming RBL until I dropped the temp tables, I was left with two
> statements that were still giving me trouble. One was the one below,
> the other another statement against t1.
>
> The o
Nope, all three were MyISAM.
After I sorted out the issue with all of the session's statements
becoming RBL until I dropped the temp tables, I was left with two
statements that were still giving me trouble. One was the one below, the
other another statement against t1.
The only thing I could
Hi, Dan!
Is t1 by any chance an InnoDB table that has a foreign key relationship
to another table that has an auto-increment column? If yes - it might be
a bug I've fixed just this week :)
On Mar 29, mari...@biblestuph.com wrote:
>
> "Statements writing to a table with an auto-increment column a
Good tip, thank you.
At first, it didn't seem helpful, since many of the statements I was
looking at did not flag a warning at all (I provided a couple examples
earlier, but there were many more that were problematic). After digging
a little further I found the explanation on this page:
http
Hi!
Try to set the binlog format to STATEMENT.
Then you should get a warning that "statement is unsafe... because ..."
That is, there will be some kind of an explanation.
On Mar 28, mari...@biblestuph.com wrote:
> Using binlog-format=MIXED I'm trying to get my head around why certain
> statement
Using binlog-format=MIXED I'm trying to get my head around why certain
statements are being written as RBR instead of as a statement. On my
10.3 test server running a fraction of my full load binary logs are
getting written to the tune of about 30M/minute (the 5.5 production
server with a curre
6 matches
Mail list logo
