Sorry
Would you be so kind as to explain your thinking.
How would upgrading Mysql fix the issue?
Regards
Brent Clark
On 20/04/2011 06:23, Suresh Kuna wrote:
Install the latest version of mysql on top of the current version and
start the database.
On Tue, Apr 19, 2011 at 9:34 PM, Brent
It will, try it out.
On Wed, Apr 20, 2011 at 1:11 PM, Brent Clark brentgclarkl...@gmail.comwrote:
Sorry
Would you be so kind as to explain your thinking.
How would upgrading Mysql fix the issue?
Regards
Brent Clark
On 20/04/2011 06:23, Suresh Kuna wrote:
Install the latest version
On 20/04/2011 10:10, Suresh Kuna wrote:
It will, try it out.
Thanks for replying.
My Colleague and I, we tried a different route.
We retried innodb_force_recovery.
But this time we started at 1 and progressed to 6.
At 6 we were able to able to start working.
So for our recovery procedure
http://pecl.php.net/package/mysqlnd_ms/download/1.0.0/
This is a really great idea to use replication-salves for
read-access without touch the php-application and if this
will work with php_flag site-specific using the available
slaves automatically / leave them out if they are stopped
this can
I'm running into some deadlocks issues.
I have this structure
accounting
|---movements
To know the balance of the account, I usualy do a sum(movements.amount)
where accounting.id=someid
The issue is that the sum is starting to run very slow due hardware
constraints, and I can't trow more
The smoothest way to avoid deadlocks, is to ensure that all your sessions lock
their tables in exactly the same order. From your explanation, that might not
be as easy as one would expect, though.
If you can't create triggers, is it acceptable to have delayed updates on the
totals? Your idea
Okie cool, Can you paste the error log details when it came up with force
recovery 6.
On Wed, Apr 20, 2011 at 6:16 PM, Brent Clark brentgclarkl...@gmail.comwrote:
On 20/04/2011 10:10, Suresh Kuna wrote:
It will, try it out.
Thanks for replying.
My Colleague and I, we tried a different
