I'm telling you the cause and I'm giving you the solution.
http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html
and/or
http://dev.mysql.com/doc/refman/5.5/en/innodb-restrictions.html
^^ go read
I have had NFS mount points lock up on servers ,usually caused by some
sort of network interruption
Putting the binlogs on an NFS server triples the failure risk, you lose
the database if:
DB server dies, NFS mount point dies, NFS server dies
Feel free to research the issues and you will see its a common issue
with InnoDB and NFS.
Contact Percona and ask them directly
https://www.percona.com/percona-support-portal
On 15-May-15 1:15 AM, Adam Fyfe wrote:
Hiya
I want to disagree, but without causing a massive argument !
I've ran Piler (with Janos' excellent help) for a while now, and ive
ran it on KVM virtualisation with iSCSI storage for MySQL
Yes, I know iSCSI and NFS are different but they should still both
survive a dirty shutdown
I think this issue reported lies elsewhere - what storage caching
model is being used ?
Adam
On 15 May 2015 at 00:11, admin-at-extremeshok-dot-com
<[email protected] <mailto:[email protected]>> wrote:
Hi Micheal
Unlike MyISAM, InnoDB will have problems on NFS.
If reliability is a consideration for your data, do not configure
InnoDB to use data files or log files on NFS volumes. Potential
problems vary according to OS and version of NFS, and include such
issues as lack of protection from conflicting writes, and
limitations on maximum file sizes.
Why do you insist on running MySQLvia nfs ? You could use
xtrabackup or mysql replication to add fault tollerance.
Networks are usually orders of magnitude SLOWER than direct hard-disk
"locking" is one thing that will reduce availability and reduce
performance
You can easily saturate your LAN if your application is database
intensive
Networks can fail - that's a fact of life
MySQL (and most contemporary databases) can recover pretty
robustly if the physical network layer hiccups during a
client/server connection It's a whole different story, however, if
the physical layer hiccups while server is trying to read a
database file that happens to be a network share.
If you're going to use a client/server architecture like MySQL,
then your server's database files should be on local disks.
Regards
Adrian
https://eXtremeSHOK.com
On 15-May-15 12:44 AM, Prof. Dr. Michael Schefczyk wrote:
Dear All,
As the database can grow quite large over time, I am running
mailpiler 1.1.1 on a virtual machine which has /var/lib/mysql
attached via nfs from a NAS device. Once in a while after an
unfriendly shutdown, the database fails. The only practical
solution I could find is to delete the InnoDB files, start
mysql, reimport the database from the last backup and run a
complete reindex. If possible, I would like the database to
survive an unfriendly shutdown without manual intervention. My
impression is that the old MyISAM storage engine (while not
transactional) is much more robust than InnoDB. Would it be
possible to change the engine in my.conf and in the tables
back to MyISAM without running into problems?
Regards,
Michael
___________________________________________________________
Technische Universität Dresden
Fakultät Wirtschaftswissenschaften
Lehrstuhl für Entrepreneurship und Innovation
Prof. Dr. Michael Schefczyk
D-01062 Dresden
Fon: +49-3 51-4 63-3 68 81 <tel:%2B49-3%2051-4%2063-3%2068%2081>
Fax: +49-3 51-4 63-3 68 83 <tel:%2B49-3%2051-4%2063-3%2068%2083>
www.gruenderlehrstuhl.de <http://www.gruenderlehrstuhl.de>
