STEP BY STEP how to Setup Mysql Replication :

This tutorial will go through the setup of MySQL database replication. I will also talk about how to get everything working smoothly again after a server crash, or if you wish to switch databases. I will try to explain what is going on behind the scenes for every step (something I've found missing from other tutorials). This is written specifically for MySQL 5.0 on Centos 4, but should be very similar on other Linux distributions. It should also work this way with MySQL 4.x.

The theory
We have 2 servers, one of which is a Master and the other which is a Slave. We tell the Master that it should keep a log of every action performed on it. We tell the slave server that it should look at this log on the Master and whenever something new happens, it should do the same thing. You should follow the instructions below with two console windows open - one for the Master and one for the Slave. Also note that I will capitalise the first letters of Master and Slave to indicate I am talking about the servers.

Configuring the Master

First of all, we need to create a user on the Master server that the Slave will connect as. I call mine 'slave_user'. Log into mysql as root and create the user: mysql -u root -p (log into MySQL)
PLAIN TEXT CODE: GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'your_password'; FLUSH PRIVILEGES;

Now, we should edit the my.cnf file (usually in /etc/my.cnf), in the [mysqld] section and tell MySQL that it's going to be a Master:
PLAIN TEXT CODE: log-bin = /home/mysql/logs/mysql-bin.log binlog-do-db=my_database server-id=1

The first line tells MySQL to start writing a log, and tells it where to write the log. Make sure this directory is empty of all replication logs, especially if you're starting again after replication has already been used. The second line chooses the database to write the log for. You should change this to your database. The third line gives the server an ID (to distinguish it from the Slave). You should also make sure skip-networking has not been enabled. You should now restart the Master:
PLAIN TEXT CODE: /etc/rc.d/init.d/mysqld restart

(MySQL restart commands may vary)

Configuring the Slave

Again, we should change the /etc/my.cnf of the Slave server, in the [mysqld] section:
PLAIN TEXT CODE: server-id=2 master-host=128.0.0.1 master-connect-retry=60 master-user=slave_user master-password=slave_password replicate-do-db=my_database

relay-log = /var/lib/mysql/slave-relay.log relay-log-index = /var/lib/mysql/slave-relay-log.index Line 1 gives the Slave its unique ID. Line 2, tells the Slave the I.P address of the Master server - so you need to change the I.P here. The remaining lines set a retry limit, and tell the Slave the user, password and database it needs to replicate. We also tell the slave what to use as its relay log. It's best to set this directly, or MySQL will create the name from the hostname and should you change hostname, replication will fail. You should also make sure skip-networking has not been enabled.

You should now restart the Slave:

PLAIN TEXT CODE: /etc/rc.d/init.d/mysqld restart

Getting the data onto the Slave

On the Master...

I'm assuming you have a live Master server, and an as yet empty Slave server. This stage depends on whether data is constantly being added to the Master. If so, we will have to prevent all database access on the Master so nothing can be added. This means your server will hang during the next step. If no data is being added to the server, you can skip this step. On the Master server, log into MySQL and do the following: mysql -u root -p (log into MySQL)
PLAIN TEXT CODE: FLUSH TABLES WITH READ LOCK;

Now we will use mysqldump to get the data out. So, still on the Master server:
PLAIN TEXT CODE: mysqldump my_database -u root -p > /home/my_home_dir/database.sql; gzip /home/my_home_dir/database.sql;

Make sure you change my_database to your database name, and my_home_dir to the name of your home directory (or another directory of your choosing). You wll now have a file called database.sql.gz in your home directory. This is a gziped copy of your database.
On the Slave...

Now we need to copy over the gzipped file. On the Slave run the following:
PLAIN TEXT CODE: scp [email protected]:/home/my_home_dir/database.sql.gz /home/my_home_dir/

Make sure 128.0.0.1 is the I.P of the Master. This will copy the file from the Master and put it in your home directory on the Slave. Now we just need to import into MySQL: mysql -u root -p (log into MySQL)
PLAIN TEXT CODE: CREATE DATABASE `my_database`; PLAIN TEXT CODE: gunzip /home/my_home_dir/database.sql.gz mysql -u root -p my_database </home/my_home_dir/database.sql

Ready to rumble...
On the Master...

Now we're ready to kick things off. We need to find the position the Master is at in the logs. So, log into MySQL and run the following: mysql -u root -p (log into MySQL)
PLAIN TEXT CODE: SHOW MASTER STATUS;

This should give you an output along these lines:

PLAIN TEXT CODE: +---------------------+----------+-------------------------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------------+----------+-------------------------------+------------------+ | mysql-bin.000001 | 21197930 | my_database,my_database | +---------------------+----------+-------------------------------+------------------+

Keep that on-screen.

On the Slave...

Log into MySQL and do the following: mysql -u root -p (log into MySQL)
PLAIN TEXT CODE: slave stop; CHANGE MASTER TO MASTER_HOST='128.0.0.1', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=21197930; slave start;

First we stop the Slave. Then we tell it exactly where to look in the Master log file. We use the values for our previous SHOW MASTER STATUS; command on the Master. You should change 128.0.0.1 to the I.P of the Master, and change the user and password accordingly. The Slave will now be waiting. So all that's left is to...
Back on the Master...

We shoud already be logged into MySQL, so all you have to do is:

PLAIN TEXT CODE: unlock tables;

To release the tables from lock. Note you only have to do this if you previously ran FLUSH TABLES WITH READ LOCK;

And the recovery part?

Several times it's happened to me that a server has crashed, or a hostname changed or whatever, and I've had a real trouble getting replication to work again. The solution has been to clear out the logs.
On the Slave

Clear out any replication logs from /var/lib/mysql or whever the logs are being stored, as stated in my.cnf. This usually does the trick:

PLAIN TEXT CODE: rm *relay* rm master.info On the Master

Again, get rid of the logs, as per where they are stored in my.cnf. For me it's the following:
PLAIN TEXT CODE: cd /home/mysql/logs/ rm -f *

This should give you a fresh start on things. You can now start again from the beginning...

Final Notes
My database doesn't use InnoDB tables - it's all MyISAM. However, the MySQL manual recommends adding this to my.cnf for InnoDB databases:
PLAIN TEXT CODE: innodb_flush_log_at_trx_commit=1 sync_binlog=1

See here for more info: http://dev.mysql.com/doc/refman/5.1/en/replication-howtomasterbaseconfig.html http://www.howtoforge.com/mysql_database_replication

Calculating the queries per second average in Mysql

I didnt find any simple ways to determine how hard our mysql database was working, so I whipped this up. It uses a 10 second delay to figure out the queries per second average.
time=10 orig=`mysql -e "show status" | awk '{if ($1 == "Questions") print $2}'` sleep $time last=`mysql -e "show status" | awk '{if ($1 == "Questions") print $2}'` diff=`expr $last - $orig` avg=`expr $diff / $time` echo "$avg"

Save the above to a text file in your ~/bin directory, or wherever you exec shell scripts from

How do I... Stress test MySQL with mysqlslap?

By Melonfire September 17, 2007, 12:12 AM PDT

Takeaway: The mysqlslap utility makes it possible to benchmark and compare MySQL performance on different hardware, as well as accurately quantify the effect of a change in database design. This tutorial shows how you can use mysqlslap to run tests involving multiple clients, custom queries, different table engines, and much more. One of the interesting new tools in MySQL 5.1.4 is mysqlslap, a load emulator that lets you see how well a particular query set or table engine performs under high-load conditions. A query that consumes too many database resources may be the result of designing tables incorrectly, choosing the wrong table type, or creating an inefficient query. When a query eats up a lot of database resources, it can negatively affect other application components. By using mysqlslap to stress test a server in a non-public environment, you will discover these errors sooner, allowing you to you avoid a database meltdown once your application goes live. This tutorial shows how you can use mysqlslap to run stress tests involving multiple clients, custom queries, different table engines, and much more.

Basic usage
This simple (and unrealistic) example uses mysqlslap to test server performance assuming only one client connection:
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql Benchmark Average number of seconds to run all queries: 0.006 seconds Minimum number of seconds to run all queries: 0.006 seconds Maximum number of seconds to run all queries: 0.006 seconds Number of clients running queries: 1 Average number of queries per client: 0

The auto-generate-sql switch tells mysqlslap to automatically generate and execute SQL statements, monitor how fast MySQL performs this task, and display the result. The results indicate that MySQL took 0.006 seconds to execute the SQL statements. The auto-generate-sql switch creates a table, executes an INSERT query and saves dummy data to it, executes a SELECT query to retrieve the dummy data, and then drops the table. You can see behind-the-scenes action by adding the -v switch to the mysqlslap command line (adding extra vs increases the verbosity level):
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql -vv DROP SCHEMA IF EXISTS `mysqlslap`; CREATE SCHEMA `mysqlslap`; CREATE SCHEMA `mysqlslap`; CREATE TABLE `t1` (intcol1 INT(32),charcol1 VARCHAR(128)); INSERT INTO t1 VALUES (1804289383,'mxvtvmC9127qJNm06sGB8R92q2j7vTiiITRDGXM9ZLzkd ekbWtmXKwZ2qG1llkRw5m9DHOFilEREk3q7oce8O3BEJC0woJsm6uzFAEynLH2xCsw1KQ1lT4zg9 rdxB L'); SELECT intcol1,charcol1 FROM t1; Benchmark Average number of seconds to run all queries: 0.007 seconds Minimum number of seconds to run all queries: 0.007 seconds

Maximum number of seconds to run all queries: 0.007 seconds Number of clients running queries: 1 Average number of queries per client: 0 DROP SCHEMA IF EXISTS `mysqlslap`;

Its unlikely that youll have only a single client connecting to the MySQL server at any given time, so youll typically also need the concurrency switch, which lets you simulate multiple simultaneous client connections, like this:
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 Benchmark Average number of seconds to run all queries: 0.698 seconds Minimum number of seconds to run all queries: 0.698 seconds Maximum number of seconds to run all queries: 0.698 seconds Number of clients running queries: 100 Average number of queries per client: 0

MySQL performance drops pretty significantly (from 0.007 seconds to 0.698 seconds) when it has to deal with 100 clients instead of just one. See what happens if you increase the number of concurrent connections even more:
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=300 Benchmark Average number of seconds to run all queries: 47.515 seconds Minimum number of seconds to run all queries: 47.515 seconds Maximum number of seconds to run all queries: 47.515 seconds Number of clients running queries: 300 Average number of queries per client: 0

Note: As you increase the number of concurrent connections, you might encounter a Too many connections error. You need to adjust MySQLs max_connections variable, which controls the maximum number of concurrent connections allowed by the server.

Running tests more than once

You can force mysqlslap to run a particular test more than once by adding the iterations switch to the command line. This example runs the same test five times and prints a composite result:
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --iterations=5 Benchmark Average number of seconds to run all queries: 0.714 seconds Minimum number of seconds to run all queries: 0.682 seconds Maximum number of seconds to run all queries: 0.753 seconds Number of clients running queries: 100 Average number of queries per client: 0

Specifying the total number of queries

Its possible to force each client to run a specific number of queries by adding the number-ofqueries switch to the mysqlslap command line. When mysqlslap encounters this switch, it divides the corresponding value by the number of concurrent connections and uses the result to decide how many queries each client should run. For example, with settings of 500 total queries and five concurrent clients, mysqlslap will run 500/5 = 100 queries per client. Take a look at an example:
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-of-queries=10000 Benchmark Average number of seconds to run all queries: 0.694 seconds Minimum number of seconds to run all queries: 0.694 seconds Maximum number of seconds to run all queries: 0.694 seconds Number of clients running queries: 100 Average number of queries per client: 100

Using larger tables

The default behavior of mysqlslap when using the auto-generate-sql switch is to create a twocolumn table with one integer column and one character column. If this isnt representative of the kind of tables you typically use, you can adjust these settings to include more integer and/or character columns, with the number-char-cols and number-int-cols switches. Here are examples:

shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-of-queries=1000 --number-char-cols=4 --number-intcols=7 Benchmark Average number of seconds to run all queries: 1.290 seconds Minimum number of seconds to run all queries: 1.290 seconds Maximum number of seconds to run all queries: 1.290 seconds Number of clients running queries: 100 Average number of queries per client: 10 shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-char-cols=4 Benchmark Average number of seconds to run all queries: 0.968 seconds Minimum number of seconds to run all queries: 0.968 seconds Maximum number of seconds to run all queries: 0.968 seconds Number of clients running queries: 100 Average number of queries per client: 0 shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-int-cols=5 Benchmark Average number of seconds to run all queries: 1.076 seconds Minimum number of seconds to run all queries: 1.076 seconds Maximum number of seconds to run all queries: 1.076 seconds Number of clients running queries: 100 Average number of queries per client: 0

Using custom queries

While the auto-generate-sql option is fine for general load testing, you may want to test the performance of a specific query on a database that already exists. In these situations, you can bypass the auto-generate-sql switch and instead tell mysqlslap to use your own custom query with the query switch. Heres the next example:
shell> /usr/local/mysql/bin/mysqlslap --user=john --create-schema=world --query="SELECT City.Name, City.District FROM City, Country WHERE

City.CountryCode = Country.Code AND Country.Code = 'IND';" --concurrency=100 --iterations=5 Benchmark Average number of seconds to run all queries: 2.886 seconds Minimum number of seconds to run all queries: 2.137 seconds Maximum number of seconds to run all queries: 4.125 seconds Number of clients running queries: 100 Average number of queries per client: 1

Its helpful to use mysqlslap in this manner when you need to analyze the effect of a change in your database structure or indexing because it allows you to immediately grasp the impact of, say, an additional index on overall performance. To illustrate, look what happens to the time needed to run the previous query when an index is added to the City table:
mysql> CREATE INDEX idx_ccode ON City(CountryCode); Query OK, 4079 rows affected (1.06 sec) Records: 4079 Bye shell> /usr/local/mysql/bin/mysqlslap --user=john --create-schema=world --query="SELECT City.Name, City.District FROM City, Country WHERE City.CountryCode = Country.Code AND Country.Code = 'IND';" --concurrency=100 --iterations=5 Benchmark Average number of seconds to run all queries: 1.682 seconds Minimum number of seconds to run all queries: 1.396 seconds Maximum number of seconds to run all queries: 2.109 seconds Number of clients running queries: 100 Average number of queries per client: 1 Duplicates: 0 Warnings: 0 mysql> exit

You can tell mysqlslap to create a custom table for your load testing by using the create command-line switch with a CREATE TABLE command.

Comparing table engines

A cool feature of mysqlslap is the ability to specify the table engine used in the test. This provides database designers with an easy way to compare the performance of different table types under different load conditions. The engine switch accepts any of MySQLs supported table types and

creates test tables using the corresponding storage engine. Heres an example of how it could be used:
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-of-queries=700 --engine=innodb Benchmark Running for engine innodb Average number of seconds to run all queries: 1.240 seconds Minimum number of seconds to run all queries: 1.240 seconds Maximum number of seconds to run all queries: 1.240 seconds Number of clients running queries: 100 Average number of queries per client: 7 shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-of-queries=700 --engine=myisam Benchmark Running for engine myisam Average number of seconds to run all queries: 0.676 seconds Minimum number of seconds to run all queries: 0.676 seconds Maximum number of seconds to run all queries: 0.676 seconds Number of clients running queries: 100 Average number of queries per client: 7 shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-of-queries=700 --engine=memory Benchmark Running for engine memory Average number of seconds to run all queries: 0.602 seconds Minimum number of seconds to run all queries: 0.602 seconds Maximum number of seconds to run all queries: 0.602 seconds Number of clients running queries: 100 Average number of queries per client: 7

Saving reports
You might wish to save a mysqlslap report so you can compare it to a previous or future test run; you may also want to use the report as a reference when youre configuring new systems. The easiest way to save a mysqlslap report is to pipe the output of a mysqlslap run to a file, as below:
shell> /usr/local/mysql/bin/mysqlslap --user=john --auto-generate-sql --concurrency=100 --number-of-queries=1000 --number-char-cols=4 --number-intcols=7 >> /tmp/output.log

You can force mysqlslap to generate reports in CSV format; this is often useful if you need to import the data into a spreadsheet or database to build graphical reports from it. To do this, add the csv switch to your mysqlslap command line and specify the output filename as an argument to this switch. Heres an example:
shell> /usr/local/mysql/bin/mysqlslap --csv=/tmp/output.csv --user=john --auto-generate-sql --concurrency=100 --number-of-queries=1000 --number-charcols=4 --number-int-cols=7

Heres what the CSV file would contain if you peeked inside it:
shell> cat /tmp/output.csv ,query,1.070,1.070,1.070,100,10

Trying mysqlslap
The mysqlslap utility makes it possible to benchmark and compare MySQL performance on different hardware, as well as accurately quantify the effect of a change in database design. Try mysqlslap out for yourself and see how well your database server behaves under pressure from thousands of client connections.

Monitoring MySQL with mytop

By Vincent Danen May 25, 2010, 5:00 AM PDT Takeaway: Vincent Danen tells you how to use mytop to monitor MySQL threads and database performance. Here are a few pointers about configuration and getting started. Mytop is a tool written in Perl for monitoring MySQL databases. Similar to how top monitors system processes, mytop monitors MySQL threads and the databases overall performance,

allowing system administrators or developers to get some insight on how applications are interacting with a database. Mytop is included in the Fedora repositories, so it is just a yum install away. If you are using Red Hat Enterprise Linux or CentOS, mytop is available via the RPMForge third-party repositories. Other distributions may provide mytop as a package, or you can install it from source by downloading it from the Web site. Mytop requires credentials to access the database, which can be provided via a prompt, on the command-line, or stored in the configuration file. In the interest of security, the best method is to use the prompt option to mytop, which asks for the password each time. If you prefer, you can store the password in the configuration file. Avoid using the -p option that allows you to provide the password as one of the command-line arguments; that will display the password in the process list for any user with access to the ps command to view. The configuration file mytop uses is ~/.mytop:
user=root #pass=sekret host=localhost db=test #port=3306 socket=/var/lib/mysql/mysql.sock header=1 color=1

The above defines the defaults mytop will use. Here you can use the pass option to store the password in the file; if you do, make sure that ~/.mytop is mode 0600 so no one other than you can read it. Also, if connecting to a local MySQL server, using the MySQL socket is better; if that is not an option use the port option to connect to the localhost on that port (default MySQL port is 3306). Provide the socket option the full path to the mysql.sock socket file (typically this file is where the MySQL databases are stored, such as /var/lib/mysql/). To start mytop, use:
$ mytop --prompt Password:

Enter your credentials for the chosen user (the user option in ~/.mytop) and you will see a top-like output:
MySQL on localhost (5.1.44) up 5+20:03:30 [11:56:50] Queries: 91.3k qps: 0 Slow: 2.0 Se/In/Up/De(%): 01/98/00/00 qps now: 2 Slow qps: 0.0 Threads: 3 ( 2/ 0) 22/00/00/00 Key Efficiency: 93.3% Bps in/out: 43.9/ 9.0 Now in/out: 111.1/ 3.0k Id User Host/IP DB Time Cmd Query or State ----------------- ----------

193 processlist 195 DISTINCT p_tag 190

rq rq rq

localhost localhost localhost

rqp rqp rqp

0 0 4

Query show full Query SELECT Sleep

One downside to mytop is that it wont display information on multiple databases at one time, so if you have a server with multiple databases, you can only observe one at a time. The advantage to mytop, however, is that it can help diagnose problems with a slow database, or help you to fine tune your code by showing you slow queries, breaking down individual tasks, and so forth. While it may not be as useful as some other development tools, it is light-weight and easy to install and use on a remote server to keep an eye on key MySQL databases.

Improve MySQL performance with MySQLTuner

By Vincent Danen October 21, 2008, 6:00 AM PDT Takeaway: Vincent Danen covers the basics of the MySQL Tuner tool, which analyzes your configuration and suggests changes that will boost the performance of your MySQL installation. MySQL is one of the most popular database packages available for any platform. It makes its mark primarily being the backend to Web applications and sites and usually the defaults are fine for most installations. With larger demand and more data, defaults are most likely inefficient and needlessly slowing down the applications that interface with it. A perl script called MySQLTuner can help you optimize MySQL configurations. This tool will suggest ways to better manage the database and ensure that enough resources are allocated to it, while at the same time ensuring MySQL resources are not being overextended. To obtain MySQLTuner, download it via wget:
$ wget mysqltuner.pl

This may not look correct, but the mysqltuner.pl Web site actually redirects to download the script of the same name. Once it is downloaded, you can immediately execute it:
# perl mysqltuner.pl >> MySQLTuner 0.9.9 - Major Hayden <major_mhtx_net> >> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--help' for additional options and output filtering Please enter your MySQL administrative login: root Please enter your MySQL administrative password: -------- General Statistics -------------------------------------------------[--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.0.45-log

[OK] Operating on 32-bit architecture with less than 2GB RAM -------- Storage Engine Statistics ------------------------------------------[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 201M (Tables: 54) [--] Data in InnoDB tables: 1017M (Tables: 55) [OK] Total fragmented tables: 0 -------- Performance Metrics ------------------------------------------------[--] Up for: 5m 1s (35 q [0.116 qps], 32 conn, TX: 24K, RX: 3K) [--] Reads / Writes: 100% / 0% [--] Total buffers: 757.0M global + 272.3M per thread (1024 max threads) [!!] Allocating > 2GB RAM on 32-bit systems can cause system instability [!!] Maximum possible memory usage: 273.0G (13983% of installed RAM) [OK] Slow queries: 0% (0/35) [OK] Highest usage of available connections: 0% (1/1024) [!!] Key buffer size / total MyISAM indexes: 8B/171.6M [!!] Key buffer hit rate: 0.0% (5 cached / 5 reads) [!!] Query cache efficiency: 0.0% (0 cached / 15 selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1 sorts) [OK] Temporary tables created on disk: 0% (0 on disk / 9 total) [OK] Thread cache hit rate: 96% (1 created / 32 connections) [OK] Table cache hit rate: 95% (126 open / 132 opened) [OK] Open file limit used: 13% (143/1K) [OK] Table locks acquired immediately: 100% (13 immediate / 13 locks) [!!] Connections aborted: 53% [!!] InnoDB data size / buffer pool: 1017.6M/512.0M -------- Recommendations ----------------------------------------------------General recommendations: MySQL started within last 24 hours - recommendations may be inaccurate Your applications are not closing MySQL connections properly Variables to adjust: *** MySQL's maximum memory usage exceeds your installed memory *** *** Add more RAM before increasing any MySQL buffer variables *** key_buffer_size (> 171.6M) query_cache_limit (> 1M, or use smaller result sets) innodb_buffer_pool_size (>= 1017M)

You will need to provide credentials to log into the database, as root, and then MySQLTuner will analyze the server and provide information regarding performance. Based on its analysis, MySQL Tuner will make some recommendations. In the sample above, you can see that MySQL is being seriously overextended, based on the amount of physical RAM available with the current buffer settings. With a maximum of 1024 threads, each consuming 272 MB, and then a global amount of allocated RAM being 757 MB, MySQL is being told that it is allowed to consume 273 GB RAM at peak connections all on a system with 2GB of physical RAM. Obviously this would need to be adjusted or, under high load, the rest of the system would suffer and/or MySQL simply wouldnt be able to accommodate the requests. In this case, it would be prudent to decrease the number of maximum threads and perhaps decrease the values of the various buffers (sort_buffer_size, read_buffer_size, and read_rnd_buffer_size; in the above example, the first two buffer sizes were set to 128MB each with the last being 64 MB).

Using MySQLTuner will help you find issues that need correcting if performance is to be improved with your MySQL install. The above example is quite severe, but serves to illustrate the potential consequences of a badly configured MySQL server.