Shinguz's blog

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

I was told that spin_wait_delay is exposed to public with the InnoDB pluggable storage engine 1.0.4. Seems I have to look for an other hidden variables now. :)

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Papagnome,

You are absolutely right, UDF’s came in in 3.23 already (I was told). What was in my mind was more the pluggable stuff. This feature is very nice an pretty new. But somehow I did not manage to express what I wanted to… :)

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Mark,

Thanks a lot for your feedback. And how is the correct way to make it version IN-dependent and thus better portable?

In one of my previous posts I was writing about how to read other processes memory
[ 1
]. As an example I tried to get the value of the hard coded MySQL internal InnoDB variable spin_wait_delay (srv_spin_wait_delay).

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Andrew pointed me to the following blog entry of Brian: [http://krow.livejournal.com/481313.html Daemon Example (deamon plugin)]

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Björn,

Thanks a lot for you post. Much better than mine! :)

Recently a colleague at Sun was asking me if MySQL can tell him to determine if we are currently in summer time or winter time. He was doing some data analysis of his house where he has installed solar panels.

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

A colleague pointed out that I was missing some information:

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Morgan,

Do not get this. With the script read_process_memory.sh you can sample at a specific interval with a timestamp in the record and write a *.csv. That must be ideal for Cacti or any other monitoring/graphing tool, is it not? You could even extend it to write directly to a database…

As you probably have experienced yet MySQL does not always provide all internal information as you might want to have them and as you are used to have from other RDBMS.

The following summary shows my personal understanding of MySQL 5.1 licenses, packages and products. It does not necessarily reflect 100% the way MySQL understands it. But after all the discussions I hope it is as close as possible to the reality:

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hey guys,

Have a look at the addendum. I have updated it.

This week we had a very interesting problem at a customer: They complained, that their MySQL Cluster takes about 1 hour for a --initial start-up. After some tuning on the hardware and the config.ini they brought it down to around 40 minutes. But this is still unacceptable long…

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Baron

Hmmm. Did not know about it. But to be honest: I did not yet have time to look at all the nice stuff from your Maatkit and all the cool Google Patches and OurDelta etc… :-(

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Willy

Yes. MySQL circular replication usually works fine (technically). I hope you have a good concept cleaning it up again when it some how messes up!

Introduction

One of the features that make MySQL so great is its easy replication set-up. If you are experienced and know-how to do it, it takes you about 15 minutes to set-up a slave. What you have in the end is a replication from one master to one or several slaves. So you can build a top-down data stream pyramid and spread your data on many slaves.

When I set-up a MySQL HA environment for customers I usually do some final failover tests after configuring the whole beast.

Das dreieckige Rad hat gegenüber dem viereckigen einen gewaltigen Vorteil: Ein Rumms weniger pro Umdrehung!

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi knetknight

Thanks for your comment.

When your are facing time/scheduling issues I recommend you to go through the MySQL online documentation (Chapter: Table Maintenance Statements and Restrictions on InnoDB Tables) because some of these commands have no effect on some table types (InnoDB) and some of them do the work already done in a previous command.

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said… Hi Matthew

Thanks for your comment. This could have helped a lot. I do NOT ask why there was no message like: