This tutorial shows how to prepare a Debian Jessie server (with Apache2, BIND, Dovecot) for the installation of ISPConfig 3 and how to install ISPConfig 3. The webhosting control panel ISPConfig 3 allows you to configure the following services through a web browser: Apache web server, Postfix mail server, Dovecot IMAP/POP3 server, MySQL, BIND nameserver, PureFTPd, SpamAssassin, ClamAV, and many more.

This post will answer how to extract database, tables etc from mysqldumpsplitter utility.

The post How-to extract from mysqldump | mysql-dump-splitter recipes first appeared on Change Is Inevitable.

I often talk with people who are very interested in the features of Percona XtraDB Cluster (PXC) such as synchronous and parallel replication, multi-node writing and high availability. However some get confused when operating a real PXC cluster because they do not fully realize the implications of these features. So here is a fun way to test your PXC knowledge: try to solve these 12 questions related to PXC! (you will find the answers at the end of the post.)

Workload

1. With Galera 3.x, support for MyISAM is experimental. When can we expect to have full MyISAM support?
a. This will never happen as Galera is designed for transactional storage engines.
b. This is planned for Galera 4.0.

2. Why aren’t all workloads a good fit for PXC?
a. Execution plans can change compared to a regular MySQL server, so performance is sometimes not as good as with a regular MySQL server.
b. Large …

The mantra of the day is – performance, performance, performance! It is clear that everything needs to be totally available all of the time, function at the fastest speeds and performance as close to perfect as is possible. In all the business discussions swirling around us we hear the words; application performance, website performance, transaction performance, server performance and on and on in regards to virtually everything digital that we live and breath with. Performance is no longer just one of the items we need to be paying attention to, it is THE item we need to be critically aware of every minute of every day! No longer are the words “it’s good enough” acceptable. The impacts to business can be catastrophic if the digital performance of your business is not at the highest levels. So the question we are all challenged with is how can we be sure that the performance levels we need are actually what we are …

So, on a large IBM POWER8 system I was recently running the newly coined “yesmark” benchmark, which is best translated as this:

Benchmark (N for concurrency): for i in {1..N}; do yes "DO 0;" | mysql > /dev/null & done
Live results: mysqladmin -ri 1 extended-status | grep Questions

Which sounds all fun until you realize that it’s *amazingly* close in results to a sysbench point select benchmark these days (well, with MySQL 5.7.7).

Since yesmark doesn’t use InnoDB though, MariaDB is back in the game.

I don’t think it matters between MariaDB and MySQL at this point for yesbench. With MySQL in a KVM guest on a shared 2 socket POWER8 I could get 754kQPS and on a larger system, I could get 1.3 million / sec.

1.3 Million queries / sec is probably the highest number anybody has ever seen out of MySQL or MariaDB, so …

At VividCortex, the algorithm our agents use to digest queries needs to be fast and reliable. Accurately digesting queries into logical groups is important to providing a useful view of data in the UI - digest too few or too many and it becomes difficult to understand what the Top-Queries view is showing.

Though our algorithm is sophisticated, one of our PostgreSQL clients experienced an issue with query digestion. They had many queries of the form “select a,b,c from table where c = any(values (1), (2), (3)…)” which were not being collapsed correctly.

We recently improved our digest code to correctly digest queries of this form.

In both MySQL and PostgreSQL, “SELECT * FROM t WHERE a IN (SELECT aa FROM tt)” was incorrectly collapsed to SELECT * FROM t WHERE a IN (?). Now, the digest is the lowercased original query text, as there is nothing to collapse or conceal.

These are improvements that help our …

TEXT fields are a nightmare. For you and for your server. It is slow to retrieve, and if you are doing searches on it, be prepared, things are going to get bumpy.

If you use MySQL with a MyISAM engine, this may not be an issue for you, you can create a FULLTEXT index, your only problem is if you want to add a new column, an alter table can take forever, since MySQL creates a new table and copies the old data to the new table. For those who uses MySQL with an InnoDB engine, prepare because, you’ll have more issues. Indexes can’t be FULLTEXT and if you do need an index you must inform the length of it. It defeats the purpose of you doing the search in that field.

The observation above is only true for MySQL 5.5 or below, since version 5.6 MySQL does support FULLTEXT indexes on InnoDB – thanks Davey …

Two weeks ago Percona announced it's acquisition of Tokutek (April 14, 2015). The analyst coverage was a bit fluffy for my liking, but I decided to give it some time and see if anything "meaty" would come along, and ... it hasn't. The sheer number of tweets on Twitter was impressive, which makes me hopeful that the acquisition raised awareness to the Tokutek technologies and that the Tokutek products have a found a good home

I've been thinking a lot about the future of the Tokutek technologies over these same two weeks and want to share them publicly. I'm going to cover TokuDB in this blog post, TokuMX in a few days, and finally Fractal Tree Indexes a few days later. [Full disclosure: I worked at Tokutek for 3.5 years (08/2011 - 01/2015) as VP/Engineering and I do not have any equity in Tokutek or Percona]

…

In previous article, we have covered some errors and issues with using MySQL in “disk full” environment. Where there was no space left on device.(See here: Testing Disk Full Conditions)

Today’s scenario is -> Starting MySQL with GTID/binary log enabled, in 0 space left Linux(CentOS 6.5) environment.

If you hit a bug or problem, general rule for helping community to fix it is to provide as much information as possible. Especially useful is to give gdb output from coredump. To get coredump you can read this wonderful article Hunting-The-Core

Now let’s explore our situation. Because our segfault is detected while starting MySQL, it is not possible to attach PID to GDB and also using strace. Our my.cnf file:

[mysqld] 
log_bin = …

After many months of heavy development and testing, Debian 8 (Jesse) and Ubuntu 15.04 (Vivid Vervet) were released recently.

For those who already upgraded their systems and/or plan do do it in close future, we prepared builds of WebScaleSQL :-)

• http://repo.psce.com/download/webscalesql/deb/x86_64/vivid/
• http://repo.psce.com/download/webscalesql/deb/x86_64/jessie/

You can also install it using PSCE repository.