In addition to our general CJK support, as detailed in this blog post, we’ve also added a MeCab parser. MeCab is a Japanese morphological analyzer, and we now have a full-text plugin parser based on it!
How Would I Use It?
The default InnoDB full-text parser is ideal for latin based languages where whitespace is the token or word separator, but for languages like Chinese, Japanese, and Korean (CJK)—where there is no fixed separators for individual words, and each word can be compromised of multiple characters—we need a different way to handle the word tokens. I’m now very happy to say that in MySQL 5.7.6 we’ve made use of the new pluggable full-text parser support in order to provide you with an n-gram parser that can be used with CJK!
…
[Read more]One of our Percona Support customers recently reported that Percona XtraBackup failed with a page corruption error on an InnoDB table. The customer thought it was a problem or bug in the Percona XtraBackup tool. After investigation we found that an InnoDB page was actually corrupted and a Percona XtraBackup tool caught the error as expected and hence the backup job failed.
I thought this would be an interesting topic and worthy of a blog post. In this article I will describe the innochecksum tool, when and how to use it and what are the possible fixes if an InnoDB table suffers from …
[Read more]My webinar “Multi-threaded Replication in MySQL 5.6 and 5.7″ on February 25 generated several excellent questions following the presentation (available here for playback along with the slides). I didn’t have time to answer many of the questions during the session and so in this post I answer all of them. Thanks to everyone who attended!
Q: What do you expect from MTS with logical clock? Do you
think performance would be good as with per database?
A: MTS with 5.6 is not usable if you have a single database. I do
not have numbers, but this is quite frequent. With 5.7 everyone
should be able to benefit from multi-threaded replication.
Q: When MySQL 5.6 was released, performance of MTS was lower,
than in 5.5, for example. Is this addressed now?
A: I
am not sure which …
Introduction
The MySQL Optimizer sometimes needs a temporary data-store during
query processing, for storing intermediate results. Before
MySQL 5.7, this need was serviced exclusively using a combination
of the HEAP/MEMORY storage engine (for smaller
tables) and the MyISAM storage engine (for larger
tables). You can find more information on when disk based
temporary tables (MyISAM or InnoDB) are used instead of MEMORY
tables here.
The …
Talking with Percona Live attendees last year I heard a couple of common themes. First, people told me that there is a lot of great advanced content at Percona Live but there is not much for people just starting to learn the ropes with MySQL. Second, they would like us to find a way to make such basic content less expensive.
I’m pleased to say we’re able to accommodate both of these wishes this year at Percona Live! We have created a two-day intensive track called “MySQL 101” that runs April 15-16. MySQL 101 is designed for developers, system administrators and DBAs familiar with other databases but not with MySQL. And of course it’s ideal for anyone else who would like to expand their professional experience to include MySQL. The sessions are designed to lay a solid foundation on many aspects of MySQL development, design and …
[Read more]Introduction
For the moment, the only engines that fully support encryption are XtraDB and InnoDB. The Aria storage engine also supports encryption, but only for temporary tables.
MariaDB supports 2 different way to encrypt data in InnoDB/XtraDB:
InnoDB Specified Table Encryption
Specified Table encryption means that you choose which tables to encrypt. This allows you to balance security with speed. To use table encryption, you have …
[Read more]If you use Percona Server 5.5 and you have configured it to use multiple buffer pool instances than sooner or later you’ll see the following lines on the server’s error log and chances are you’ll be worried about them:
InnoDB: detected cycle in LRU for buffer pool 5, skipping to next buffer pool. InnoDB: detected cycle in LRU for buffer pool 3, skipping to next buffer pool. InnoDB: detected cycle in LRU for buffer pool 7, skipping to next buffer pool.
Worry not as this is mostly harmless. It’s becoming a February tradition for me (Fernando) to face a question about this subject (ok, it’s maybe a coincidence) and this time I’ve teamed up with my dear colleague and software engineer George Lorch to provide you the most complete blog post ever published on this topic … (with a belated thank you! to Ernie Souhrada, with whom I’ve also discussed this same …
[Read more]
During the process of reviewing our server defaults for MySQL 5.7,
we thought that it might be better to change the default transaction isolation level from
REPEATABLE-READ to READ-COMMITTED (the
default for PostgreSQL, Oracle, and SQL Server). After some
benchmarking, however, it seems that we should stick with
REPEATABLE-READ as the default for now.
It’s very easy to modify the default isolation level, however,
and it can even be done at the SESSION level. For
the most optimal performance you can change the transaction
isolation level dynamically in your SESSION according …
default_tmp_storage_engine variable was introduced
in 5.6.3, allowing the configuration of the default engine for
temporary tables. This seems to be in the direction, as I
commented before, of making MyISAM an optional engine. In 5.7,
a separate tablespace is being created to hold
those tables in order to reduce its performance penalty
(those tables do not need to be redone if the server crashes, so
extra writes are avoided).
However, I have seen many people assuming that because
default_tmp_storage_engine has the value “InnoDB”,
all temporary tables are created in InnoDB format in
5.6. This is not true: first, because implicit
temporary tables are still being created in memory using …
