strange problem here - any ideas?
did anyone ever see a similar problem?
we haven´t found the cause yet - and thus no solution.
here´s the problem:
a php script, a daily cron job, sends a (massive) number of delete query to the mysql master. On occasions, after one of these deletes, mysql_affected_rows() returns 0 though it should be 1.
any subsequent delete does fail in the same way. sometimes it does a few deletes, even thousands, but in most cases none at all.
the first query failing is always sent (explicitly to the master) immediately after a select query to the load balancer.
other scripts, selecting the record (not) deleted, sometimes behave as if the result was empty. seems to me that the delete query hit one of the slaves, though they are explicitly sent to the db master.
the problem probably does not only occur in this script; some other smaller unresolved issues might be explained by this. But those only occur occasionaly, while this one script regularly fails.
But with logging slowing down the website too much, I cannot even do an error log.
environment:
multicore, (mostly) multiprocessor systems running the latest php 4 and mysql 4.0 versions; all components are self-compiled.
(yes I know, php4 and mysql4 are both "dead". migration to php5 is done, will soon be upgraded; migration to mysql5 is underway)
did anyone ever see a similar problem?
we haven´t found the cause yet - and thus no solution.
here´s the problem:
a php script, a daily cron job, sends a (massive) number of delete query to the mysql master. On occasions, after one of these deletes, mysql_affected_rows() returns 0 though it should be 1.
any subsequent delete does fail in the same way. sometimes it does a few deletes, even thousands, but in most cases none at all.
the first query failing is always sent (explicitly to the master) immediately after a select query to the load balancer.
other scripts, selecting the record (not) deleted, sometimes behave as if the result was empty. seems to me that the delete query hit one of the slaves, though they are explicitly sent to the db master.
the problem probably does not only occur in this script; some other smaller unresolved issues might be explained by this. But those only occur occasionaly, while this one script regularly fails.
But with logging slowing down the website too much, I cannot even do an error log.
environment:
multicore, (mostly) multiprocessor systems running the latest php 4 and mysql 4.0 versions; all components are self-compiled.
(yes I know, php4 and mysql4 are both "dead". migration to php5 is done, will soon be upgraded; migration to mysql5 is underway)
