Re: [SLUG] MySQL maintenance
Not sure of this case but I've seen some web hosts using non-ECC memory. Darin On Sat, Jun 28, 2014 at 2:45 PM, James Linder j...@tigger.ws wrote: On 28 Jun 2014, at 10:00 am, slug-requ...@slug.org.au wrote: I've been using MySQL for CMS and mail like for ever, on physical servers and vm servers with no problems that I can recall, ever. on the new vm, in use about 6 month, couple of weeks ago joomla cms went down, traced to corrupt MySQL table, fixed with phpmyadmin, all good yesterday noticed cacti not working / failed few weeks ago (perhaps at similar time to joomla, need to check that), again, traced to corrupt MySQL table with two failures, getting a little concerned, need to look into some regular/preventive maintenance? to detect failure at MySQL before results of failure are realized ? what do people do with MySQL in such terms ? should I run mysqlcheck at regular basis? thanks for pointers and suggestions I use mysql for (amongst others) mythtv. I note that on a power fail 3 times out of 4 mysql is FOOBAR. This sorts corrupt tables, but how why ? etc on ext4 drives mysqlcheck --auto-repair --check -u mythtv -pmythtv mythconverg or mysqlcheck --auto-repair -A -u mythtv -pmythtv mythconverg perhaps (match to your distro) in rc.local James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] MySQL maintenance
On 28/06/14 14:45, James Linder wrote: I use mysql for (amongst others) mythtv. I note that on a power fail 3 times out of 4 mysql is FOOBAR. This sorts corrupt tables, but how why ? etc on ext4 drives mysqlcheck --auto-repair --check -u mythtv -pmythtv mythconverg or mysqlcheck --auto-repair -A -u mythtv -pmythtv mythconverg perhaps (match to your distro) in rc.local James It is for this particular reason that I convert all mythtv's myisam tables to innodb. It is ACID compliant, so that a powerfail doesn't leave you with a screwed table. I suggested to the myth devs that they change to innodb by default and was basically laughed at, as if you don't run a UPS on your media machine, also inno isn't available by default on some ancient releases of some distros. With recent mysql (5.5) the default engine has changed to innodb so odds are a recent clean install will already be in innodb, if you are running from an older database you will want to do the conversion. I haven't tested this since 2008 but this is the script I used to do the conversion (take a backup first) for t in $(mysql --batch --column-names=false -e show tables mythconverg |grep -v exclude_this); do mysql -e alter table $t type=InnoDB mythconverg; done This will take a while depending on how big your database is and the spec on your system. I'd suggest shutting mythbackend down first. Oh to fix broken recordings in the table (when you jump around you skip random times not 30 seconds or whatever) find /var/lib/mythtv/recordings -iname *.mpg -mtime -4 -print0 | xargs -0 -n1 mythcommflag --rebuild --file That will re-build the seektable for any file modified in the last 4 days. It'll take a while to run but its pretty quick, quicker than standard commflag. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] MySQL maintenance
On 28 Jun 2014, at 18:45, Jake Anderson ya...@vapourforge.com wrote: I suggested to the myth devs that they change to innodb by default and was basically laughed at This is pretty common, and pretty indicative of the MythTV developers’ attitude in general. I once suggested they support PulseAudio natively and I was thanked with accusations of trolling. I also suggested they support IPv6 and judging by the reaction you would have thought I accidentally misspelled “IPv6” as “die in a fire”. Ironically, a couple of point releases later, they now support both PulseAudio and IPv6 quite well, so I guess the moral of the story is that if you are in the right, eventually you will win. You just need to outvoice the conservatives first. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] MySQL maintenance
I've been using MySQL for CMS and mail like for ever, on physical servers and vm servers with no problems that I can recall, ever. on the new vm, in use about 6 month, couple of weeks ago joomla cms went down, traced to corrupt MySQL table, fixed with phpmyadmin, all good yesterday noticed cacti not working / failed few weeks ago (perhaps at similar time to joomla, need to check that), again, traced to corrupt MySQL table with two failures, getting a little concerned, need to look into some regular/preventive maintenance? to detect failure at MySQL before results of failure are realized ? what do people do with MySQL in such terms ? should I run mysqlcheck at regular basis? thanks for pointers and suggestions V -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] MySQL maintenance
on the new vm, in use about 6 month, couple of weeks ago joomla cms went yesterday noticed cacti not working / failed few weeks ago (perhaps at similar time to joomla, need to check that), again, traced to corrupt MySQL table fwiw, joomla failure was noticed 2nd June, cacti stopped around 31st May, so it's possible it was same time ? jtablesession::Store Failed DB function failed with error number 145 Table './dom.tld/jos_session' is marked as crashed and should be repaired SQL=INSERT INTO `jos_session` ( `session_id`,`time`,`username`,`gid`,`guest`,`client_id` ) VALUES ( '20o43hn493po7fhv2jp7pji2e2','1401675661','','0','1','0' ) Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 72 bytes) in /dom.tld/public_html/libraries/joomla/error/exception.php on line 117 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] MySQL maintenance
Possible hardware (Hard-disk) failure? While mysql will probably run forevever, the same assumption can't be made for the magnets in the hard-disks. Which can over time lose their workingness. On Sat, Jun 28, 2014 at 10:54 AM, li...@sbt.net.au wrote: on the new vm, in use about 6 month, couple of weeks ago joomla cms went yesterday noticed cacti not working / failed few weeks ago (perhaps at similar time to joomla, need to check that), again, traced to corrupt MySQL table fwiw, joomla failure was noticed 2nd June, cacti stopped around 31st May, so it's possible it was same time ? jtablesession::Store Failed DB function failed with error number 145 Table './dom.tld/jos_session' is marked as crashed and should be repaired SQL=INSERT INTO `jos_session` ( `session_id`,`time`,`username`,`gid`,`guest`,`client_id` ) VALUES ( '20o43hn493po7fhv2jp7pji2e2','1401675661','','0','1','0' ) Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 72 bytes) in /dom.tld/public_html/libraries/joomla/error/exception.php on line 117 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] MySQL maintenance
Which storage engine and which version of Mysql? They were not all made equal. Otherwise, like others said, I'd look at hardware issues. On 28 Jun 2014 10:46, li...@sbt.net.au wrote: I've been using MySQL for CMS and mail like for ever, on physical servers and vm servers with no problems that I can recall, ever. on the new vm, in use about 6 month, couple of weeks ago joomla cms went down, traced to corrupt MySQL table, fixed with phpmyadmin, all good yesterday noticed cacti not working / failed few weeks ago (perhaps at similar time to joomla, need to check that), again, traced to corrupt MySQL table with two failures, getting a little concerned, need to look into some regular/preventive maintenance? to detect failure at MySQL before results of failure are realized ? what do people do with MySQL in such terms ? should I run mysqlcheck at regular basis? thanks for pointers and suggestions V -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] MySQL maintenance
On 28 Jun 2014, at 10:00 am, slug-requ...@slug.org.au wrote: I've been using MySQL for CMS and mail like for ever, on physical servers and vm servers with no problems that I can recall, ever. on the new vm, in use about 6 month, couple of weeks ago joomla cms went down, traced to corrupt MySQL table, fixed with phpmyadmin, all good yesterday noticed cacti not working / failed few weeks ago (perhaps at similar time to joomla, need to check that), again, traced to corrupt MySQL table with two failures, getting a little concerned, need to look into some regular/preventive maintenance? to detect failure at MySQL before results of failure are realized ? what do people do with MySQL in such terms ? should I run mysqlcheck at regular basis? thanks for pointers and suggestions I use mysql for (amongst others) mythtv. I note that on a power fail 3 times out of 4 mysql is FOOBAR. This sorts corrupt tables, but how why ? etc on ext4 drives mysqlcheck --auto-repair --check -u mythtv -pmythtv mythconverg or mysqlcheck --auto-repair -A -u mythtv -pmythtv mythconverg perhaps (match to your distro) in rc.local James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
