Back on January 21, 2009, Peter Zaitsev stated the following on mysqlperformanceblog.com
As the call for action – I would surely like someone to see if EXT3 can be fixed in this regard as it is by far the most common file system for Linux. It is also worth to investigate if something can be done on MySQL side – may be opening binlog with O_DSYNC
flag if sync_binlog=1
instead of using fsync will help ? Or may be binlog pre-allocation would be good solution.
As of yet, I know of no one having touched this issue. O_DSYNC
as a default is not an appealing prospect but does accommodate faster writes that are not really verified. That why there is so much hype around O_DIRECT
.
I can tell you do not have the InnoDB Plugin installed. With the InnoDB Plugin, several variables should exist.
You should upgrade InnoDB in one of two ways:
Once you have done so, you can enhance InnoDB to
- access more CPUs and Cores
- increase read and write I/O threads
- scale the I/O capacity (this is especially needed for different storage media)
Here are my past posts on the settings you can change for this:
Based on our chat conversation, here is what was discussed
- Server1 is Stand Alone
- Server2 is a Master
- Server3 is a Slave to Server2
This implies that binary logging is enabled in Server2.
To Make Server1 a Master of Server2, perform the following:
STEP 01 : On Server2, add this to /etc/my.cnf
[mysqld]
log-slave-updates
STEP 02 : On Server3, run STOP SLAVE;
STEP 03 : On Server2, run service mysql restart
STEP 04 : On Server3, run START SLAVE;
STEP 06 : On Server1, add this to /etc/my.cnf
[mysqld]
log-bin=mysql-bin
STEP 07 : On Server1, run service mysql restart
STEP 08 : Set Replication From Server1 to Server2
See Clarification about master slave configuration in mysql
OPTIONAL
Once you have MySQL Replication Going From Server1 to Server2 to Server3, your can properly load all data into all three MySQL Instances by doing the following on Server1:
mysqldump -u... -p... --all-databases --routines --triggers > mysqldata.sql
mysql -u... -p... < mysqldata.sql
This will do three(3) things
- Repopulate everything into Server1
- MySQL Replication will handle populating Server2 from Server1
- MySQL Replication will handle populating Server3 from Server2
Since your data is 50MB in total, this should be execute very quickly.
Best Answer
I actually wrote about this back on August 27, 2012 : Proper tuning for 30GB InnoDB table on server with 48GB RAM. Here is an excerpt from my past answer (under the section entitled
Log File Size
):EXCERPT
5MB
is the default size for innodb_log_file_size. Percona's mysqperformanceblog.com gave two good articles on computing the right size for your particular MySQL instance:Basically, the blog recommends measuring how many bytes are written to the InnoDB Log Files in one hour. This is what I run to figure that out
END OF EXCERPT
Where do you go from here?
Run these commands every hour for a week. When you ascertain the highest number for
@MB_WL_HR
, take half of it and resize innodb_log_file_size to it : See my post How to safely change MySQL innodb variable 'innodb_log_file_size'?CONCLUSION
Since you can figure out the proper InnoDB Log File Size in this manner, there is no need to pool the
show engine innodb status\G
for anything, especially since you said it is not available in MySQL 5.0.Keep in mind that my answer works for MySQL 5.1/5.5. So, how do you did this for MySQL 5.0?
It's a good thing the status variable Innodb_os_log_written exists in MySQL 5.0.
Looking back, here is your original question:
With MySQL 5.0 you have to do this:
Then subtract and multiply like you did before:
Give it a Try !!!