PlanetMysql.ru — информация о СУБД MySQL

[UPDATE 2011/01/11] : New poll added, vote for the best GUI client tool ! (And continue to vote for other polls)
And thanks again for your involvement. It’s time to vote again… 

First of all, I wish you a happy new year.
Many things happened last year, it was really exciting to be involved in the MySQL ecosystem.
I hope this enthusiasm will be increased this year, up to you !

To start the year, I propose the MySQL+ Community Awards 2011
It will only take 5 minutes to fill out these polls.
Answer with your heart first and then with your experience with some of these tools or services.

Polls will be closed January 31, so, vote now !
For “other” answers, please,  let me a comment with details.

Don’t hesitate to submit proposal for tools or services in the comments.
And, please, share these polls !

 

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Happy 2012 !
Cédric

This article is obviously not sponsored !
(MySQL is a trademark of Oracle Corporation and/or its affiliates)

Sources :

• Oracle products, tools and services : http://www.mysql.com
• SkySQL products, tools and services : http://www.skysql.com
• Percona products, tools and services : http://www.percona.com
• FromDual products, tools and services : http://www.fromdual.com
• PalominoDB products, tools and services : http://palominodb.com/
• Pythian products, tools and services : http://www.pythian.com/
• Blue Gecko products, tools and services : http://www.bluegecko.net/
• Zabbix : http://www.zabbix.com/
• MySQL Cacti templates : http://code.google.com/p/mysql-cacti-templates/
• Nagios : http://www.nagios.org/
• r1soft CDP for MySQL : http://www.r1soft.com/linux-cdp/cdp-enterprise-edition/mysql/ 
• mylvmbackup tool : http://www.lenzg.net/mylvmbackup/
• mydumper tool : http://www.mydumper.org/
• ZRM tools : http://www.zmanda.com
• Galera replication : http://codership.com/products/galera_replication
• Tungsten replicator : http://code.google.com/p/tungsten-replicator/
• DRBD : http://www.drbd.org/
• ShoonerSQL : http://www.schoonerinfotech.com/products/schoonersql
• ScaleBase : http://www.scalebase.com/
• common-schema : http://code.google.com/p/common-schema/
• innotop : http://code.google.com/p/innotop/
• MySQL Tuner : https://launchpad.net/mysqltuner/2.0/mysqltuner-2.1-rev17
• mycheckpoint : http://code.openark.org/forge/mycheckpoint
• MariaDB : http://mariadb.org/
• TokuDB : http://www.tokutek.com/
• InfiniDB : http://infinidb.org/
• Drizzle : https://launchpad.net/drizzle
• Amazon SimpleDB : http://aws.amazon.com/fr/simpledb//180-2635771-0721067/
• mongoDB : http://www.mongodb.org/
• Cassandra : http://cassandra.apache.org/
• CouchDB : http://couchdb.apache.org/
• Tokyo Cabinet : http://fallabs.com/
• Riak : http://basho.com/
• Hadoop : http://hadoop.apache.org/
• Tarantool : http://tarantool.org/
• memcached : http://memcached.org/
• MySQL Sandbox : http://mysqlsandbox.net/
• openark kit : http://code.openark.org/forge/openark-kit
• Redis : http://redis.io/
• Ganglia : http://ganglia.sourceforge.net/
• HandlerSocket : https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL

PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL is developing rapidly.  And today it does not only happen along a single track but in multiple directions simultaneously.

This is due to both server ‘forks‘ as well as various plugins and 3rd party storage engines available.   Each of those will often add  information that can be fetched from the server – typically in the form of additional Information_Schema tables. This content can now also be utilized for monitoring MySQL servers with MONyog. MONyog 4.8  implements monitoring based on Custom SQL Objects.  It is basically just a SQL query. Any query returning a result set can be used for monitoring.  MONyog will collect results from the query and you may define counters on it exactly as you want.

It is really very simple.  In this example we will utilize the `accounts` table that was added to the `performance_schema` database in MySQL 5.6.3 (but you could also use the ‘user statisitics plugin’ originally published as a Google patch and now distributed with MariaDB) . Basically only two steps are required:

First step: Navigate to TOOLs tab .. Customization .. Manage Custom SQL Objects .. Add/Edit Custom SQL Objects and here enter the query. Note that you must also define a unique column (or a unique set of columns).

Also define the sample interval and the retention timeframe for this particular query and on what MySQL servers the query should be executed.  MONyog will now start collecting the data as you have specified.

Second step: Navigate to Monitors/Advisors tab .. Add new Monitor/Advisor. The result of the query you defined in first step is exposed as a javascript array to the MONyog javascript engine. Enter the  javascript defining the content, display, formatting etc. of the new counter in order to make it display as you want. Add an advisor text as well  if you want.

You have now created a Custom SQL Counter based on the Custom SQL Object Object that was defined in first step. You may create a new counter group for the new counter what we have done here:

.. but in this particular case it would also make perfect sense to add the new counter to the existing ‘current connections’ group. Also note that if you want to define WARNING and CRITICAL thresholds on a counter and alert on it, the SQL and/or javascript must be framed in such a way that the counter returns a plain number.

We would like to hear your feedback – and not at least how you use this in your environment. What are you monitoring now that you did not before?

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

PlanetMySQL Voting: Vote UP / Vote DOWN

We are delighted to announce the release of MONyog 4.8 GA. This release is all about customization – to be precise Custom SQL Objects (CSO) and Custom SQL Counters (CSC).

The above diagram shows how Monitors & Advisors (MySQL Counters) are populated. MONyog has a repository of SQL Queries which are executed in regular interval of time & the results are stored in SQLite database of MONyog. These results are exposed as JavaScript objects and are referenced to populate Monitors and Advisors (MySQL Counters).

With CSO, you can add your own SQL queries to this repository & customise counters based on that. Discussed below are some cases on how useful CSOs can be.

• Maintenance statements, for eg. CHECK TABLE, REPAIR TABLE etc.
• You could query on Information Schema to monitor the size of a table. You can also configure it to alert when it crosses a threshold.
• Keep yourself updated with the worst performing indexes.
• Third party MySQL forks have some non standard tables. For eg. you can query on Statistics table of Percona MySQL fork to fetch information about unused index.
• You can monitor MySQL clusters too, by querying Ndbinfo Schema.

Refer the following posts for detailed release notes:

• MONyog 4.8 Beta 2 Released
• MONyog 4.8 Beta 1 Released

MONyog customers can download the latest installer from Webyog’s Customer Portal.

To evaluate MONyog, please download the 30-day trial.

We are very excited about this release, and hope you like it. We would love to hear from you.

Regards,
Team MONyog

PlanetMySQL Voting: Vote UP / Vote DOWN

Regardless of the monitoring tool you use to monitor your databases, it can be better to monitor this tool.
No, it’s not a joke ! Do you think you can have a benefit with a monitoring tool not connected to your servers ? ( without being alerted )

I choose to talk about MONyog here but this can apply to all existing monitoring tools.
I just want to share the message, the tool does not matter, so, do it !

So, let me explain how to control if you have fresh data with MONyog.
With MONyog it’s easy because it’s an agentless monitoring tool.

There are two ways to check that :

Per server general info :

 

 

 

 

 

 

For each server, you can find the last data updated date in the Monitors/Advisors tab.
The MySQL Availability in the dashboard is also usefull.

But it’s a per server information, so, that can be boring if you have a lot of databases servers.

General log file :

 

The default location for this file is MONyog_PATH/MONyog.log on your MONyog server.
You can find usefull informations there about MySQL, SFTP or SSH connexion failures for all your databases servers, in one place.

This log can also be used to detect client side errors if you don’t have access to the application servers.

Hope that can help, tell us what is the best method to do that with others monitoring tools like MySQL Enterprise Monitor.

Have a nice week-end.

PlanetMySQL Voting: Vote UP / Vote DOWN

This is a follow-up om my first Blog on performance_schema that appeared here:

One particular request that we had frequently from our users is to have status variables exposed per database and maybe even per table. Currently this is not possible. Not even with MySQL 5.6.3 with the P_S additions found there. I have frequently experienced that users get frustrated why ‘such a simple thing’ is not possible and I have the impression that they sometimes tend not to believe me!

Examples: the (GLOBAL) status variables ‘slow_queries’, ‘com_update’ etc. has no database/table -level information. For those MySQL users that run a lot of different applications (both standard applications – Forums software, Blogging software etc. – as well as applications dedicated to the particular business of the organization) on same server this would be extremely usable. It is not always easy to identify the reason for a sudden or periodic increase of a status variable. If the database context was exposed it would in most scenarios be possible to identify the application causing this and then it would be much easier to analyze.

It is to some extent possible to get such information from logs of course, but enabling general log has a penalty and parsing logs is complicated alone by the fact that sometimes a ‘fully qualified’ table name is used and sometimes a USE statement + a non-’fully qualified’ table name is used. The USE statement may appear in the general log Gigabytes before statements using it! Also use of log tables (for general log in particular) has penalties.

Retrieving the information from P_S could be framed like this:

SELECT database, table, query, query_time FROM performance_schema.queries WHERE slow_query = 1 and com_insert = 0 ORDER BY query_time DESC;

Also aggregation like “.. GROUP BY database ..” could be useful. If memory is a problem the P_S tables could have aggregated information only. Even that would be helpful in some cases.

I don’t know how much trouble it would be to add such instrumentation. I realize that queries (JOIN’s, UNION’s, subqueries) may reference more tables and even different tables in more databases, but even that should be possible to solve somehow (record it twice if there are two tables referenced, for instance).

I would find a feature/instrumentation like this in P_S extremely useful. More useful (for me) than much of the stuff you’ll find there now.

PlanetMySQL Voting: Vote UP / Vote DOWN

What does FLUSH STATUS do? We all know that it will simply reset all status variables (except for ‘uptime’) to same values as immediately after a server restart. Just google it and you will find that behaviour statet on hundreds of sites on the Internet.

But NO – it is not true! Not anymore. MySQL documentation:
http://dev.mysql.com/doc/refman/5.5/en/flush.html

“This option adds the current thread’s session status variable values to the global values and resets the session values to zero. It also resets the counters for key caches (default and named) to zero and sets Max_used_connections to the current number of open connections.”

This bug report http://bugs.mysql.com/bug.php?id=22875 has some background. Before introduction of seperate SESSION and GLOBAL status variables, FLUSH STATUS really did reset (almost) all status variables to same values as immediately after a server restart.  Now it affects SESSION status variables (but why is SUPER privilege required for this?) and a few GLOBAL status variables only.

From the bug report I think that the change of behavior was not really planned and specified properly in advance but came as some kind of surprise – also to some people in the MySQL developer team. I agree with Konstantin Osipov’s (one of those MySQL developers that seemed surprised) comment in the bug report:

“As this behaviour got broken in 4.1, I personally consider it a regression and believe that it should be fixed as a regression. In order to fix it in line with the design of SHOW [SESSION/GLOBAL] STATUS we should implement FLUSH GLOBAL STATUS.FLUSH STATUS behaviour should be modified to not change any global data,  such as:
- key cache counters
- connection counters
- SHOW_LONG global variables.In other words, FLUSH STATUS should behave as FLUSH SESSION STATUS and only reset session-scope status variables. [SESSION] keyword should be added to the grammar and as optional.Key cache counters, connection counters, SHOW_LONG variables and server-scope status variable (those that have session counterparts) should be reset by FLUSH GLOBAL STATUS. FLUSH SESSION STATUS should no longer require SUPER privilege (connection privilege is enough, and as long as it is checked at connection, no privilege check is necessary).FLUSH GLOBAL STATUS should require SUPER privelege.”

But what happened was that the new behaviour was simply documented and since the problem/the report has been abandoned. It is now 5 years ago. Nothing happened since. The bug report is still open with the status of ‘verified’.

The reason why I am writing this is that I just replied to a concern to a MONyog user on whether MONyog could be fooled by this when calculating counters in the “ALL TIME” timeframe. The answer is that it cannot provided the actual server has implemented the GLOBAL status variable ‘uptime_since_flush_status’. All recent servers have (only very early 5.0 and 5.1 servers (5.0.35-,  5.1.24-) that nobody should use today have not). MONyog will simply discard all collected information older than ‘uptime_since_flush_status’ even if it has not yet been purged from the MONyog embedded database.

But still: Can we soon have that SESSION|GLOBAL switch for FLUSH STATUS, please? What we have now is a mismatch both as regards the semantics and the privileges requried. And 5 years of ‘stand-still’ for a ‘verified’ bug report related to server core features is too much (even though it is probably not the only one).

PlanetMySQL Voting: Vote UP / Vote DOWN

I have for the first time been spending some time trying to understand the performance_schema. It is not easy to understand everything unless you are very well-versed in server internals (what I am not) and much information available here is probably more useful for server developers and testers than for ordinary users. But anyway some of the P_S tables are reasonable simple and useful. For instance the ‘accounts’ and ‘hosts’ tables (introduced in MySQL 5.6x) are immensely useful for everybody.

The reason why I spent time with this now was (I am totally egoistic, of course) that we just released the first beta in a new MONyog release cycle where you may expose P_S contents for monitoring. Please refer this Blog.

However I have two concerns with the P_S implementation. This derives from the fact that P_S is to some extent  updateable for users having sufficient privileges. You may for instance disable/enable ‘consumers’ and decide whether information should be recorded in counts of CPU clock-cycles or microseconds etc. Also some tables may be truncated in order to discard old information and free memory.

The interface for this is standard SQL statements (UPDATE, TRUNCATE). IMHO this leads to two problems/concerns:

1) Server restart. If the server restarts all P_S settings are reset to default. The UPDATEs from last running instance are lost. I am  simply missing a mechanism to load the UDPATEs again automatically at startup. I do not favour of introducing of a lot of new server startup options and variables (that would be around 100 I think if all cases should be covered and there already are more than enough options IMHO). One option could be a P_S configuration file (‘performance_schema.ini’) or maybe an EVENT executing at startup (“at startup” could be a useful schedule setting for an EVENT in other contexts as well – but it is not in any server version currently). Also the problem cannot be worked around an automated way currently on Windows as far as I can see, as on this platform the server is not started by a ‘script’ but by an executable (the ‘Windows Service Manager’). On Unix-type platforms you may modify the server startup script adding a call to Perl/Python/whatever script performing the updates on the P_S tables.

2) Multi-user environment. If for instance GRANTS for ‘peter’@'thishost’ are like “GRANT CREATE USER, SELECT,UPDATE ON *.* TO ‘peter’@'thishost’ WITH GRANT OPTION;” then peter may “GRANT SELECT,UPDATE ON performance_schema.* TO ‘jimmy’@'thathost’;”. Now both peter and jimmy can UPDATE the P_S tables that are updateable. But the problem is that one of the users may do so without the knowledge of the other resulting in unexpected results. The only solution I found was LOCKING (example: “LOCK TABLES performance_schema.setup_consumers READ;“). I don’t find it fully satisfactory however, but I have no better solution with current implementation and also no usable idea for an improved implementation.  

Any thoughts?

PlanetMySQL Voting: Vote UP / Vote DOWN

Introduction:

If you have been using MONyog you will know that any metrics/counters may be identified with either of the ‘states’ STABLE, WARNING and CRITICAL. For those metric where it is relevant MONyog ships with settings for this that are (to the extend possible) commonly agreed ‘best practices’ by MySQL DBA’s. Metrics in a WARNING or CRITICAL state display with a (yellow or red) ‘marker’ indicating that this metric is not in a STABLE state. For metrics in a CRITICAL state further an alert can be sent (as a mail alert and/or a SNMP trap).

If the ‘best practices’ we have implemented in MONyog do not fit your environment or use case, it can easily be customized. Open the MONyog ‘Monitors/Advisor’ page, click on the name of the metric you want to adjust (it is a link). A small popup opens. As an example let us take the ‘Connection usage’ in the ‘Current connections’ group. In the popup you will see the settings for this metric. They are defined like this

Warning = 75
Critical = 85

To change the settings click ‘Customize’ in the popup and next ‘View Advanced’ to see all options. It will open in a new browser tab. If you are willing to allow the number of current connection to reach 90% of the max_connections allowed before the state should change to CRITICAL  just enter “90″ as the value for the threshold of the CRITICAL state and save.

Differentiating thresholds for different MySQL servers:

What we described above will have effect for all MySQL servers monitored. It was also meant to be an introduction only.  The real  question to be dealt with here is different however: Is it possible to have different ‘state’ settings for different MySQL servers?

The answer is YES, and it is very simply to do actually. Say you monitor 2 servers that you in MONyog have named “Testserver” and “Production” respectively, and that you want a CRITICAL setting of “90″ for “Testserver” and “80″ for “Production”. Then the CRITICAL setting is not a constant (applying for all MySQL servers) anymore, but a condition needs to be added. MONyog exposes connection details to different MySQL servers monitored as Javascript objects that can be referenced with a simple if/case-condition. And it is very simple to work with. Just replace the constant with a (javascript-)function like this

function()
{
if(MONyog.Connections.ConnectionName == “Testserver”) return 90;
if(MONyog.Connections.ConnectionName == “Production”) return 80;
}

Below a (reduced) screenshot of values entered in the customizations page:

.. and now save. That is all. Now the CRITICAL condition for this metric is defined differently for the MySQL servers “Testserver” and “Production”.

Note that everything happens centrally at the MONyog level and there is nothing to do on the MySQL servers monitored. And also there is no need for any other program or utility (such as a database client or whatever) to do this. MONyog is agent-less and self-contained.

The objects that can be referenced in the customization interface are listed in the MONyog documentation here along with the explanation of the ‘MONyog Object Model’: http://www.webyog.com/doc/MONyog/MONyog_object_model.htm

In the above image we have defined different WARNING and CRITICAL values for another metric (‘percentage of max_allowed reached’ in the ‘Connection history’ group) for two servers: For “Testserver” WARNING is set at 84% and CRITICAL at 90% and for “Production” CRITICAL is set at 87%. You will notice the red and yellow ‘markers’ displaying accordingly.

(There is one more detail you should be aware of: MONyog will not necessarily alert using mail or SNMP first time a CRITICAL value has been reached. There is a setting for this as well. The default setting is that the CRITICAL condition must have been in existence for 5 consecutive data retrievals from MySQL. This setting is specific for every MySQL server registered in MONyog and is available  in the MONyog ‘Register servers’ page for each server, but the value can be overridden for an individual metric by setting the “RetryOverride” value from the customizations page. Please be aware of this when testing or you may become confused why you don’t get the alerts you’d expect)

Download the MONyog whitepaper: http://www.webyog.com/en/whitepapers/MONyogWhitePaper.pdf
Read the MONyog documentation online: http://www.webyog.com/doc/index.php
Download MONyog TRIAL: http://webyog.com/en/downloads.php
Purchase MONyog: http://webyog.com/en/buy.php

PlanetMySQL Voting: Vote UP / Vote DOWN

We are pleased to announce the release of MONyog 4.7 GA. Below is a brief on new features:

Dashboard

The world is moving towards tablets (I agree iPad in the title is a misnomer) and most of them don’t support Adobe Flash. As you know MONyog dashboard charts were on Flash and did not work on tablets. With this release we have switched to HTML5 charts. Not only do they work on all Smartphones and Tablets, they are faster than Flash charts. Hence, desktop users also gain from this release.

Flash charts used elsewhere in MONyog are also changed to slick HTML5 charts.

Embedded in this post are screen-shots with relevant section zoomed-in on an iPad.

MONyog dashboard in action

Disk Usage Info

Wayback Machine

Who doesn’t like Wayback Machine? Well, MONyog gets one of its own. A neat way of tracking MySQL variables/Status and Queries fired while looking at historic “Number of threads connected” & “Number of slow queries” data. The user gets a chance to see the graphs of “Number of threads connected” & “Number of Slow Queries”, typically a spike on this chart would need attention. Zooming on this spike gives details like Status/Variables/Queries in that zoomed time range. We can also get details at a certain point in time.

Wayback Machine

Replication Tab

Monitoring replication is now even easier. Thanks to the all new ‘Processlist’ like interface to monitor MySQL replication. This tab details the current MASTER & SLAVE STATUS.

MONyog customers can download the latest installer from Webyog’s Customer Portal.

To evaluate MONyog, please download the 30-day trial.

We are very excited about this release, and hope you like it. We would love to hear from you.

Regards,
Chirag
Team MONyog

PlanetMySQL Voting: Vote UP / Vote DOWN

We are pleased to announce the release of MONyog 4.7 GA. Below is a brief on new features:

Dashboard

The world is moving towards tablets (I agree iPad in the title is a misnomer) and most of them don’t support Adobe Flash. As you know MONyog dashboard charts were on Flash and did not work on tablets. With this release we have switched to HTML5 charts. Not only do they work on all Smartphones and Tablets, they are faster than Flash charts. Hence, desktop users also gain from this release.

Flash charts used elsewhere in MONyog are also changed to slick HTML5 charts.

Embedded in this post are screen-shots with relevant section zoomed-in on an iPad.

MONyog dashboard in action

Disk Usage Info

Wayback Machine

Who doesn’t like Wayback Machine? Well, MONyog gets one of its own. A neat way of tracking MySQL variables/Status and Queries fired while looking at historic “Number of threads connected” & “Number of slow queries” data. The user gets a chance to see the graphs of “Number of threads connected” & “Number of Slow Queries”, typically a spike on this chart would need attention. Zooming on this spike gives details like Status/Variables/Queries in that zoomed time range. We can also get details at a certain point in time.

Wayback Machine

Replication Tab

Monitoring replication is now even easier. Thanks to the all new ‘Processlist’ like interface to monitor MySQL replication. This tab details the current MASTER & SLAVE STATUS.

MONyog customers can download the latest installer from Webyog’s Customer Portal.

To evaluate MONyog, please download the 30-day trial.

We are very excited about this release, and hope you like it. We would love to hear from you.

Regards,
Chirag
Team MONyog

PlanetMySQL Voting: Vote UP / Vote DOWN