MySQL Tcpdump system : use percona-toolkit to analyze network packages

We can identify problem SQLs with high execution frequency.

With DBMON system and AWR system we can find problem SQLs in a special time (high frequency, occurs over a period of time)

View this PDF:

http://www.vmcd.org/docs/MySQL_TCPDUMP.pdf

Practical tips and a live demo of how to get your data warehouse loading projects off the ground quickly and efficiently when replicating from MySQL and Oracle into Amazon Redshift, HP Vertica and Hadoop.

Webinar-on-demand. Recorded 07/23/15.

While MONyog MySQL Monitor is being embraced by DBAs and DevOps around the world, we are constantly adding more features to make MONyog the most complete MySQL monitoring tool.

MONyog ships 40+ MySQL and system metric charts. It also lets you add custom charts. With the latest update, we have made Charts more powerful by adding few important features to help you find problem queries with ease.

Here’s a 1 minute video to walk you through the new features.

Existing customers can download MONyog 6.33 from Customer Area. To evaluate MONyog 6.33, please download a 14-day trial.

We are really excited about this update and we hope you like the new features. Please feel free to share your feedback.

Cheers,
Team MONyog

The post …

Thank you for attending my July 15 webinar, “Creating Best in Class Backup solutions for your MySQL environment.” Due to the amount of content we discussed and some minor technical difficulties faced near the end of webinar we have decided to cover the final two slides of the presentation along with the questions asked by attendees during the webinar via this blog post.

The slides are available for download. And you can watch the webinar in it’s entirety here.

The final two slides were about our tips for having a …

[…] = CRC32. This is because innodb_checksum_algorithm = INNODB is the default setting. See this post for a sample […]

Dear community, maybe you have already tested, there are new added features in MySQL 5.7. See previous post -> About 5.7.7-rc BUGs

“General Tablespace” feature -> From now you can place tables to separate tablespaces. Prior, on our hands there were only “System TableSpace” and “InnoDB file per table” options. Today’s topic is altering table to use this “General Tablespace”.

Our sample table structure:

mysql> show create table t1;

    | Table | Create Table 
    | t1    | CREATE TABLE `t1` (
      `id` int(11) DEFAULT NULL,
      `c1` varchar(85) DEFAULT NULL
    ) /*!50100 TABLESPACE innodb_file_per_table */ ENGINE=InnoDB DEFAULT CHARSET=utf8 

Note that there is a comment about tablespace of our table -> /*!50100 TABLESPACE …

Welcome to MySQL QA Episode 8: Reducing Testcases for Engineers: tuning reducer.sh

1. Advanced configurable variables & their default/vanilla reducer.sh settings
   1. FORCE_SKIPV
   2. FORCE_SPORADIC
   3. TIMEOUT_COMMAND & TIMEOUT_CHECK
   4. MULTI_THREADS
   5. MULTI_THREADS_INCREASE
   6. QUERYTIMEOUT
   7. STAGE1_LINES
   8. SKIPSTAGE
   9. FORCE_KILL
2. Some examples
   1. FORCE_SKIPV/FORCE_SPORADIC
   2. TIMEOUT_COMMAND/TIMEOUT_CHECK

Full-screen viewing @ 720p resolution recommended.

The post MySQL QA Episode 8: Reducing Testcases for Engineers: tuning reducer.sh …

[…] ← innodb_fast_checksum=1 and upgrading to MySQL 5.6 […]

Summary: My checklist for performing an in-place MySQL upgrade to 5.6. Details: In my previous post, I discussed the problem I had when doing an in-place MySQL upgrade from 5.5 to 5.6 when the database had been running with innodb_fast_checksum=1. … Continue reading →

I recently worked with a customer who had a weird issue: when their MySQL server was started (Percona Server 5.5), if they try to run service mysql start a second time, the init script was not able to detect that an instance was already running. As a result, it tried to start a second instance with the same settings as the first one. Of course this fails and this creates a mess. What was the issue? A missing rule in SELinux. At least it looks like

Summary

If SELinux is set to enforcing and if you are using Percona Server on CentOS/RHEL 6 (other versions could be affected), service mysql start doesn’t work properly and a fix is simple to run:

# grep mysqld_safe /var/log/audit/audit.log | audit2allow -M mysqld_safe
# semodule -i mysqld_safe.pp
# service mysql restart

Other options are:

• Set SELinux to permissive
• Use the CentOS/RHEL standard MySQL init script …