Tag Info

Hot answers tagged

5

OBSERVATION #1 Since your buffer pool is 6G (6144M), the innodb_log_file_size should be 1536M (25% of 6G) OBSERVATION #2 You have sync_binlog set to 1. This provides the safest ACID compliant setup. It can also slow things down dramatically. You say it seems as though its writing each row 1 at a time to disk. That's the case because each completed DML ...


4

XtraDB replaces InnoDB (it's compatible and a drop in replacement), so just add ENGINE = InnoDB However, it should be the default in MySQL 5.5.x onwards


3

It seems to be fixed (see percona manual): Feature has been removed because the upstream DROP TABLE implementation has been improved.


3

When I head the word 'Percona Server', the first thing that jumps at me is : "Does the DB Server have multiple CPUs?" These days, that is taken for granted. What is unfortunate is that most people forget to configure MySQL or Percona Server to summon those multiple CPUs. MySQL 5.1 with InnoDB 5.1 Plugin, MySQL 5.5 and Percona Server have options to increase ...


2

I think you want wsrep_sst_method=skip not wsrep_sst_mode=skip mysql> show variables like 'wsrep_sst%'; +---------------------------+------------+ | Variable_name | Value | +---------------------------+------------+ | wsrep_sst_auth | | | wsrep_sst_donor | | | wsrep_sst_method | ...


2

The binlog doesn't contain different structures when the storage engine is XtraDB vs InnoDB. In the sense of interoperability, XtraDB is not an "extension" of InnoDB -- it's a fully-compatible replacement, that handles some internal operations differently but is still very much "InnoDB" wherever it is exposed outside the server core. For what it's worth, ...


2

As shown from your SHOW PLUGINS;, InnoDB is present. XtraDB is also present. If you want to be sure, you must run SHOW ENGINES;. That will show what storage engine is the default. The fact that the XtraDB plugins are active shows that XtraDB must be in use.


1

Unless your WordPress site is huge, you are unlikely to see much performance improvement in switching to TokuDB, if any at all. TokuDB's 20x performance advantage is for an indexed insertion workload, where the secondary indexes do not fit in memory. You will be using less space on disk with TokuDB's compression.


1

The method of using 'innodb_plugin' instead of default InnoDB is a MySQL 5.1 feature. The InnoDB plugin of 5.1 is the default of MySQL 5.5, and thus, in MySQL 5.5 we see this information for the 'ignore_builtin_innodb': In MySQL 5.1, this option caused the server to behave as if the built-in InnoDB were not present, which enabled InnoDB Plugin to be used ...


1

If the table reportingdb.norep_zonebannertmp_bk does not exist on one of the nodes in the Cluster, this could be the source of your problem. Why? TRUNCATE TABLE is DDL. That will close the current transaction PXC has during WriteSet Operations. This cannot be rolled back. I would expect a PXC communication problem at COMMIT time because TRUNCATE TABLE causes ...


1

You should index as per usage. If you drop all indexes for the benefit of a small % of your workload you will hit pain elsewhere. Run pt-duplicate-key-checker 1st and remove the redundant keys. Then review your queries with pt-query-digest and weed out the poorly performing queries by reindexing them or rewriting them. You could paste the output of EXPLAIN ...


1

Performance enhancement may be possible without major upgrade to the next version of MySQL or a Migration to MariaDB. MySQL is the default database by which everyone else creates forks or introduces new things Different Storage Engines TokuDB PBXT ScaleDB and Others Improved Storage Engines XtraDB over InnoDB TokuDB over InnoDB New Features not ...


1

Percona's Xtradb has some improvements -- mostly in scalability. The changed the Mutexes, which held back effective use of multiple cores.


1

IMHO there should be no real difference. However, let me add this: I actually wrote something up on this a while back How do I properly perform a MySQL bake-off? Why mysql 5.5 slower than 5.1 (linux,using mysqlslap) Query runs a long time in some newer MySQL versions In my posts, I mentioned InnoDB 5.1 Plugin outperforming native InnoDB 5.1, 5.5, 5.6 ...


1

InnoDB in Percona Server 5.0.91 and MySQL 5.5.x has three options innodb_read_io_threads innodb_write_io_threads innodb_io_capacity These options were introduced in MySQL 5.1.38 InnoDB Plugin Tuning these will engage more CPUs within InnoDB/XtraDB I have discussed this in past posts in the DBA StackExchange along with other InnoDB tuning suggestions ...



Only top voted, non community-wiki answers of a minimum length are eligible