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

Not counting obtaining the source code, and once you have the prerequisites satisfied, [Windows] users can build from source code in 5 easy steps.

Prerequisites – Install & ensure they are in the $PATH:

1. CMake <-- Download
2. Make <-- 3.75 or newer
3. C++ compiler <-- Visual Studio 2008 Express - Free Download
4. Bison <-- Download (ensure m4.exe is also included, which it should be)

Optional (but most likely you’ll want):

5. Perl <-- For Test Suite/Scripts. Strawberry Perl is a great option.
6. Bazaar <-- If want latest source tree

Tip: Install these in locations where spaces are not in the path. Specifically, watch for the Bison/m4 as there is a known bug with regards to that.

..

Now that that’s out of the way, we can begin. You just need to decide if you want to build from source code you download or from the latest development tree.

This will walk through building from the latest development tree (since the downloaded version requires no extra steps – just grab it from any mirror).

Also, this post assumes you can connect to the Launchpad repository via Bazaar and download the source (i.e., you’ll have to create SSH keys to connect to Launchpad – see this write-up for more details. You might also need Pageant too, if you don’t already have it.)

I. Prerequisite Checks:

C:\>cmake --version
cmake version 2.6-patch 4

C:\>make --version
GNU Make 3.81

C:\>c++ --version
c++ (GCC) 4.4.3

C:\>bison --version
bison (GNU Bison) 2.4.1

C:\>m4 --version
m4 (GNU M4) 1.4.13

C:\>perl --version
This is perl 5, version 12, subversion 3

C:\>bzr --version
Bazaar (bzr) 2.4.1

..

II. Obtain Source Code (skip this if you download the source directly from a mirror):

1. Open Pageant -> Add Key -> Select your SSH Key (for Launchpad)
2. cd C:\
3. bzr init-repo –trees mysql-5.5
4. cd mysql-5.5
5. bzr branch lp:mysql-server/5.5 mysql-5.5

..

III. Build/Compile Source Code:

1. cd mysql-5.5
2. cmake . -DBUILD_CONFIG=mysql_release -G “Visual Studio 9 2008″
3. Copy m4.exe to $basedir/sql <-- this avoids any m4.exe errors
4. Open Solution in VS: File -> Open -> Project/Solution -> C:\mysql-5.5\mysql-5.5\MySQL.sln
5. Now build in VS: Build -> Build Solution (or F7)

========== Build: 93 succeeded, 0 failed, 5 up-to-date, 10 skipped ==========

There you have it! (Assuming you have “0 failed”, otherwise, you’ve got some debugging to do.)

Build Notes (step #2 above):

The -DBUILD_CONFIG=mysql_release flag uses the same build options used for official releases, which are stored in cmake/build_configurations/mysql_release.cmake.

The simplest you could use is: cmake . -G “Visual Studio 9 2008″

Or you could specify a number of options: cmake . -DMYSQL_SERVER_SUFFIX=-chris -DWITHOUT_FEDERATED_STORAGE_ENGINE=1 -DWITHOUT_BLACKHOLE_STORAGE_ENGINE=1 -G “Visual Studio 9 2008″

The -G lets know which compiler will be used. In this case, I’m using VS 2008 Express. If you were using VS 2005, it’d be “Visual Studio 8 2005″, but I’m not sure if VS 2005 will even work.

This command should end with something like “– Build files have been written to: C:/…” or you’ll need to debug.

Lastly, the cmake command creates the MySQL.sln file and all .vcproj files.

..

IV. Kicking the tires …

I believe since I’m using the Express edition, I cannot create a nice package for Windows (perhaps I’m wrong about this).

But any way, I can piece it together easily enough:

1. Make main dir mysql-5.5.xx
2. Make subdir bin/ - copy in all .exe files (from client/debug, sql/debug, */debug, etc.)*
3. Make subdir data/ - copy from sql/data/
4. Make subdir scripts/ – copy from scripts/ (at least all perl, sql, and sh scripts)
5. Make subdir share/ - copy from sql/share/
6. Create my.ini

* Notes re: .exe files: mysqld.exe is located in /sql/debug/ and mysql.exe is located in /client/debug/. The remaining .exe files are located in /client/debug/, /sql/debug/, /extra/debug/, /libmysql/debug/, /mysys/debug/, /scripts/debug/, /storage/myisam/debug/, /storage/heap/debug/, and /tests/debug/.

Now start mysqld:

mysql> select version();
+------------------+
| version()        |
+------------------+
| 5.5.21-debug-log |
+------------------+

Of course you should test it a bit more than that, but I’ll leave that to you.
 
 

Any re-implementations of this protocol must also be under GPL, unless one has got an license from MySQL AB stating otherwise.

$ bzr annotate --long --all  sql/net_serv.cc |  head -n 24 |tail -n 9
2476.648.3   cmiller@xxxxx   20071011 | /**                   
2476.648.3   cmiller@xxxxx   20071011 |   @file
2476.648.3   cmiller@xxxxx   20071011 | 
1616.1722.3  joerg@xxxxx     20050307 |   This file is the net layer API for the MySQL client/server protocol,
1616.1722.3  joerg@xxxxx     20050307 |   which is a tightly coupled, proprietary protocol owned by MySQL AB.
2476.648.3   cmiller@xxxxx   20071011 |   @note
1616.1722.3  joerg@xxxxx     20050307 |   Any re-implementations of this protocol must also be under GPL
1616.1722.3  joerg@xxxxx     20050307 |   unless one has got an license from MySQL AB stating otherwise.
1616.1722.3  joerg@xxxxx     20050307 | 

$ bzr branch -r tag:mysql-4.1.2 lp:mysql-server/5.1 branch4.1.2
$ cd branch4.1.2
$ bzr annotate --long --all  sql/net_serv.cc |  head -n 24 |tail -n 9
2           bk@xxxxxxx  20000731 |                             
1098.3.1    monty@xxxx  20020723 | /*
1538.19.1   monty@xxxx  20030604 |   This file is the net layer API for the MySQL client/server protocol,
1538.19.1   monty@xxxx  20030604 |   which is a tightly coupled, proprietary protocol owned by MySQL AB.
1538.19.1   monty@xxxx  20030604 |   Any re-implementations of this protocol must also be under GPL
1538.19.1   monty@xxxx  20030604 |   unless one has got an license from MySQL AB stating otherwise.
1538.19.1   monty@xxxx  20030604 | */
1538.19.1   monty@xxxx  20030604 | 
1538.19.1   monty@xxxx  20030604 | /*

$bzr log -r 1538.19.1
------------------------------------------------------------
revno: 1538.19.1
committer: monty@xxxx
timestamp: Wed 2003-06-04 18:28:51 +0300

Why a New Utility?

A couple of months back, Tim Procter, Sheeri Cabral and I were discussing about how best to diagnose a MySQL server and/or tune its performance, automating the process as much as possible. The Performance Advisors from MySQL Enterprise do this, but most of our customers don’t have a subscription and Pythian’s collective experience is not necessary reflected by its rules.

In our daily work, we have used Major Heyden’s MySQL Tuner, Mark Leith’s Statpack and our own tools to review a MySQL server configuration parameters. However, all of these tools had limitations in regards of what we wanted to achieve. Our major concern was the need to keep historical data to draw conclusions based on trends and cross check with other time based tools. The conclusion of our conversations was that whatever scripts we would implement, it would need to monitor all configuration and status variables, and their evolution over time.

One day, while looking into slave lag problem, the idea of MySAR popped into my head and a few hours later I was using its first incarnation. I was able to relate the server’s I/O activity peaks with these lags and in turn, discovered that it was caused by a great number of INSERT statements coming in in waves. It was an encouraging outcome for what was nothing more than a proof of concept.

MySAR’s Goal

Major Heyden’s MySQL Tuner, Mark Leith’s Statpack, and our own scripts already do analysis and recommendations. Not wishing to reinvent the wheel, I decided that the best thing to do was to gather as much data as possible and store it in the database, from which it can be extracted to perform any kind of manipulations. My intention, then, is, to limit MySAR to be just a sampling tool. In short, to keep it simple.

What Does MySAR Do?

MySAR does nothing else than record the output of SHOW GLOBAL STATUS, SHOW GLOBAL VARIABLES, and SHOW FULL PROCESSLIST commands, or a subset of them. The idea is to invoke MySAR from the crontab (or similar tool on Windows) at regular intervals. Data older than 30 days is purged by default to avoid accumulating too much data on disk. We usually run it every ten minutes so it will be roughly in sync with sar’s output.

Where to Get MySAR and Participate

I have decided to use Bazaar and Launchpad to track the project: http://launchpad.net/mysar. I found it to be the most convenient alternative. Consider the code to be in the alpha stage—not necessarily feature-complete and with bugs. The trunk branch has the most stable version (the current development branch has been merged into the trunk).  But if you just want the latest public tarball, you can use the download link in the project Launchpad page.

The documentation is provided in plain text, HTML, and perldoc formats (perldoc mysar.pl) as part of the tarball. It is complete since I use it as a specification document and gets written before the code is complete. You can download the HTML manual following this link.

Please record bugs, questions, suggestions in the appropriate sections of the site and I’ll address them as best I can. I invite the community at large to contribute with use cases and examples in the Answers section, and I’ll post the most creative contributions as FAQs (along with the real FAQs). I don’t expect too much in the beginning. Hopefully the contributions will start coming in once it proves as useful as it has been for us so far.

Installation

At this point the requirement are only the DBI and DBI::mysql Perl modules. To install follow these steps:

1. Download the latest tarball from the download link on the Launchpad page.
2. Untar on any subdirectory using:

   tar -xzf mysar.tar.gz

3. Create a schema to hold it’s tables (or use an existing schema with the –database option). The default schema name is mysar. Example:

    CREATE DATABASE mysar;

4. Make sure the user already exists and has full access to this schema. Example to grant the permissions:

   GRANT ALL ON mysar.* TO 'username'@'localhost'

5. Run at least once to create the tables. The mimimum command line required is:

   mysar --user username --pass password --status / variables

   Either –status or –variables should be used. Currently there is a bug (Launchpad’s bug #441006) when you run with –status for the first time, which can be safely ignored.

I will be blogging different use cases based on real cases in the near future, including how to easily draw colorful graphics using the Google Charts API, so stay tuned.