On 7/11/2006 11:57 AM, Scott Marlowe wrote:
> On Tue, 2006-07-11 at 10:45, Jan Wieck wrote:
>> On 7/10/2006 10:00 PM, Alex Turner wrote:
>>
>> > http://dev.mysql.com/doc/refman/5.1/en/replication-row-based.html
>> >
>> > 5.1
>>
>> Ah, thanks. So I guess 5.1.5 and 5.1.8 must be considered major feature
>> minor/bugfix releases. I still don't understand how people can use
>> software in production that has literally zero bugfix upgrade path
>> without the risk of incompatibility due to new features. I consider
>> every IT manager, who makes that choice, simply overpaid.
>
> Dear god! That page made my eyes bleed.
>
> Individual users can choose the method of replication for their
> sessions?
>
> There's a mixed method that switches back and forth?
It is totally unclear from that page what would make the server decide
when to pick one or the other method. It seems to me that this is mainly
an optimization for many single inserts in order to get a smaller
binlog. Note that according to this page
http://dev.mysql.com/doc/internals/en/replication-prepared-statements.html
the master currently substitutes the parameters as literals into the
query for prepared statements.
What also is totally unclear, maybe someone with more MySQL experience
can answer this question, is if the binary format actually does solve
the problems discussed. Namely timestamps and also autoincrement. What
exactly happens if an insert doesn't provide a value for an autoinc or
timestamp column? Is the server chosen value placed into the binlog when
using row format or not?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #