New answers tagged percona
The InnoDB/XtraDB is a table engine, it has no say in parsing SQL. Thats another layer, which should be mostly engine independent. MariaDB 5.5 is supposed to be 99.99% SQL compatible with MySQL 5.5 (there were some minor hiccups) and MariaDB 10.x is backward compatible with 5.5. With MariaDB 10 and MySQL 5.6 (and now 5.7) the paths diverged somehow - some ...
Just going by the MySQL Documentation, I would say yes. According to the MySQL 5.6 Documentation on innodb_adaptive_hash_index Disabling the adaptive hash index empties the hash table immediately. Normal operations can continue while the hash table is emptied, and executing queries that were using the hash table access the index B-trees directly ...
No - the MyISAM architecture prohibits hot backups - it uses a locking mechanism. You might be interested to my response in a related thread. Take a mysqldump of your database, change the bit where it says ENGINE=MyISAM to ENGINE=InnoDB (InnoDB uses a MVCC architecture) and then restore - XtraBackup will then perform hot backups. It's relatively easy to use ...
It is not advisable to use RAM for temporary directory. At time files can grow large enough to outflow RAM and this would be true even with plain MySQL. RAM is best managed by InnoDB buffer pool. You can setup a tmpfs that should be good enough with decent performance.
Thanks for your answer. I have checked the connections on both servers. But the results are strange. On the Master DB server there are more connections than on the slave: Master netstat | grep TIME_WAIT | wc -l 148 htop mysql VIRT 44G RES 34,7G Slave netstat | grep TIME_WAIT | wc -l 78 htop mysql VIRT 174G RES 68G
You should not be using MySQL 5.6.20 at all. Why ? I wrote this post back on Nov 14, 2014 : Find MySQL Patch Level where I had just found out about Oracle's Security Patch. My company had upgraded to 5.6.20. To our horror, the security patch then came out of nowhere. We had to redeploy MySQL Installation in puppet to upgrade to 5.6.21. I still need a ...
We ran an update with extra parameters and it completed. In the end, we didn't alter the chunk-size but instead altered the default settings for the copy-rows process, to increase the number of retries and the interval between retries. We also increased the innodb_lock_wait_timeout from the default 1 second to 5 seconds --set-vars ...
You seem to be asking the right questions and that seems like a reasonable course of action. Don't be surprised if this runs for a few weeks.
Top 50 recent answers are included