Am 04.09.2012 01:15, schrieb Titanus Eramius: >> where do you see a risk of silent data corruption? >> >> if this would be the case it would be simply >> impossible have a omplete dbmail-database running >> on a replication salve over 3 years with a lot of >> foreign constraints and a major scheme update >> >> there is NO silent corruption >> please do not post FUD > > I'm somewhat sorry for being unable to ask my question in a manner that > can't be misunderstood, but I suppose it's always possible to find > someting negative if you are looking for it.
that is not the point > Like I said "I've been reading up on the subject, but seems to lack the > experince ..." which should be understood as I don't know anything > about the subject besides what I have read. > > Like this > http://www.iheavy.com/2012/04/26/bulletproofing-mysql-replications-with-checksums/ * mixed transactional and non-transactional tables not relevant in this context why would someone mix innodb/myisam a database and transaction? * use of non-deterministic functions such as uuid() not relevant in this context * stored procedures and functions not relevant in this context * update with LIMIT clause not relevant in this context even if, combined with a clear "order by" no problem > So I'm sorry, I don't see the FUD, and because I know next to nothing > about databases, I simply can not see these replication errors as > anything else than corruption*. But please enlighten me, that was why I > posted to the list. for postfix lookup tables you have usually a very simple database scheme with very few changes and 99.9% of all queries are readonly because postfix does even not need any write permissions to the database (and does not have it in any of my setups) so you have a simple webinterface for updates or if you have only a few domains/users maybe phpMyAdmin or terminal would be enough so there is virtually zero danger for get out of sync
signature.asc
Description: OpenPGP digital signature
