Join us for a live and interactive webinar session where we will demonstrate how to start an evaluation of the MySQL Cluster database in 5 easy steps, and then how to expand your deployment for web & telecoms-scale services.
Just register here:
http://www.mysql.com/news-and-events/web-seminars/display-566.html
Getting Started will describe how to:
Scaling for HA and the web will describe how to:
When: Wednesday, September 08, 2010: 09:00 Pacific time (America)
Wed, Sep 08: 11:00 Central time (America) Wed, Sep 08: 12:00 Eastern time (America) Wed, Sep 08: 16:00 UTC Wed, Sep 08: 17:00 Western European timeThe presentation will be approximately 45 minutes long followed by Q&A.
Here are some quick commands for installing the proper packages and requirements for the MySQL dbbenchmark program.
export PKG_PATH="ftp://openbsd.mirrors.tds.net/pub/OpenBSD/4.7/packages/amd64/" pkg_add -i -v wget wget http://dbbenchmark.googlecode.com/files/dbbenchmark-version-0.1.beta_rev26.tar.gz pkg_add -i -v python Ambiguous: choose package for python a 0: 1: python-2.4.6p2 2: python-2.5.4p3 3: python-2.6.3p1 Your choice: 2 pkg_add -i -v py-mysql pkg_add -i -v mysql pkg_add -i -v mysql-server ln -s /usr/local/bin/python2.5 /usr/bin/python gzip -d dbbenchmark-version-0.1.beta_rev26.tar.gz tar -xvf dbbenchmark-version-0.1.beta_rev26.tar cd dbbenchmark-version-0.1.beta_rev26 ./dbbenchmark.py --print-sql - login to mysql and execute sql commands ./dbbenchmark.pyUnless you set sync_binlog = 1, a system crash on the master will likely fail any slave with an “Client requested master to start replication from impossible position” error. Generally, this kind of situation requires manual intervention. When we see this, we make sure things indeed failed “past the end” of a binlog (i.e. the bit that didn’t get to the physical platter before the crash), reposition the slave to the next binlog, and use the Maatkit tools to ensure the slave is properly synced.
sync_binlog=1 is a problem in itself, because it makes the server not just do one fsync per commit, but several and that’s serious overhead. sync_binlog is actually not a boolean but a “fsync binlog every N commits” where 0 meaning “never”. So you could set it to 10 (fsync every 10 commits) and thus reduce the loss a little bit while not doing too much harm to performance. But it’s not ideal and won’t always prevent the above error.
As previously mentioned, Darren Cassar has been working on a new automated installer for the DBbenchmark program. It’s now available for download: click here. All you need to do is save it to the directory that you want to install to and then make sure it’s executable: “chmod 700 installer.sh”, then run it “./installer.sh”.
How long it may take MySQL with Innodb tables to shut down ? It can be quite a while.
In default configuration innodb_fast_shutdown=ON the main job Innodb has to do to complete shutdown is flushing dirty buffers. The number of dirty buffers in the buffer pool varies depending on innodb_max_dirty_pages_pct as well as workload and innodb_log_buffer_size and can be anywhere from 10 to 90% in the real life workloads. Innodb_buffer_pool_pages_dirty status will show you the actual data. Now the flush speed also depends on number of factors. First it is your storage configuration – you may be looking at less than 200 writes/sec for single entry level hard drive to tens of thousands of writes/sec for high end SSD card. Flushing can be done using multiple threads (in XtraDB and Innodb Plugin at least) so it scales well with multiple hard drives. The second important variable is your workload, especially how dirty pages would line up on the hard drive. If there are a lot of sequential pages which are dirty Innodb will be able to use larger size IOs – up to 1MB flushing dirty pages which can be a lot faster than flushing data page by page.
So if we have system with single hard drive doing 200 IO/ssc, 48G buffer pool which is 90% dirty and completely random page writes we’ll look at 13500 seconds or about 5min per 1GB of Buffer pool size.
This is worse case scenario though it is quite common in practice to see shutdown time of about 1min per GB of buffer pool per hard drive.
Baron has written a nice post how to decrease innodb shutdown time which you may want to read on this topic.
Entry posted by peter | No comment
So far the benchmarking script supports Linux, FreeBSD, and OSX. I’m installing virtual machines today to get ready for development on the next OS that the community wants to have supported. Vote today for your choice. Development will begin Friday 2010-09-03.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.At yesterdays Eigenbase Developer Meetup at SQLstream’s offices in San Francisco we arrived at a new logo for LucidDB. DynamoBI is thrilled to have supported and funded the design contest to arrive at our new mascot. Over the coming months you’ll see the logo make it’s way out to the existing luciddb.org sites, wiki sites, etc. I’m really happy to have a logo that matches the nature of our database - BAD ASS!
Often, the first step in evaluating and deploying a database is to load an existing dataset into the database. In the latest version, TokuDB makes use of multi-core parallelism to speed up loading (and new index creation). Using the loader, MySQL tables using TokuDB load 5x-8x faster than with previous versions of TokuDB.
Measuring Load PerformanceWe generated several different datasets to measure the performance of TokuDB when doing a LOAD DATA INFILE … command. To characterize performance, we vary
All generated keys, including the primary, are random, 8-byte values. The remaining data, needed to pad out the row length to specified length, is text.
Two files files are produced as part of data generation.
For instance, if the number of keys is 3 and the row length is 256 bytes, the following SQL statement is produced:
CREATE TABLE load_table (\ val0 BIGINT UNSIGNED NOT NULL,\ val1 BIGINT UNSIGNED NOT NULL,\ val2 BIGINT UNSIGNED NOT NULL,\ pad VARCHAR(232) NOT NULL,\ PRIMARY KEY (val0),\ KEY valkey1 (val1),\ KEY valkey2 (val2)\ ) ENGINE=tokudbWe can make the data generation program available if anyone is interested.
Load TestA simple shell script
For the experiments to be meaningful, we created datasets that do not fit in memory.
ResultsWe ran our benchmark on an Amazon Web Services c1.large node with 8 cores and 7 GB of memory. The test loads 100M rows (NOT pre-sorted). The data file was on a 2 disk RAID-0, the MySQL DB files on a different 2 disk RAID-0.
TokuDB Version 3 (~single-threaded) v. TokuDB Version 4 (multi-threaded) Keys Row Len v3 rows/s v4 rows/s Speedup 1 64 27K 142K 5.1 4 64 13K 82K 6.2 1 256 7K 54K 7.2 4 256 5K 43K 8.2 Other metricsSeveral metrics can be used to measure performance:
Metrics for TokuDB v4:
Keys Row Len Rows/sec KV-pairs/sec MB/sec 1 64 142K 142K 9.1 4 64 82K 330K 5.3 1 256 54K 54K 13.9 4 256 43K 173K 11.1These results show
We will report further results, especially speedups on larger CPU count machines, as they become available.
(English version) Herhalde bildiğiniz gibi, biz tamamen sanal şirketiz, yani ana merkez gib bir şeyimiz yok. Hepimiz evinden çalışıyor ve biz sadece bir ya da iki kez yılda gerçek hayatta buluşuyorus. Bu sene kararımız İstanbul‘a düştü. Firmadaki tek Türk ben olduğumdan dolayı toplantının organizesi bana düştü.
İlk adım olarak böyle bir toplantının özelikleri nedir ve en iyi şekilde nasıl hazır edilir diye araştırdım. Kaj Arnö bunun ayrıntılarını blog’unda açıklamış bile: How to arrange a physical meeting in a virtual organisation. Kaj ile İstanbul’a 2008′de gelmiştik ve çeşitli konferanslar vermiştik.
İlk toplantı tarihi ile ilgili bir anket yaptık ve İstanbul’daki toplantı Ekim ayına karar verdik. Tam olarak, Perşembe, 7 Ekim’den Salı, 12 Ekim 2010′a kadar.
Yaklaşık 30 kişilik toplantıyı düzenlemek pek bir basit görev değil, bu nedenle toplantıyı hazırlanmak için bana bir asistan tahsis edildi – oldukçada ünlü bir asistan – My Widenius. My (okunuşu Mü) MySQL’ın My’sü ve ona bir mariadb.org e-posta adresinle ulaşabilisiniz.
Eğer Ekim’in başında İstanbul’da iseniz, sizi bizim toplantıya davet etmekten mutluluk duyarız. Üç toplantı günleri olacaktır: Cuma 8 Ekim, Cumartesi 9 Ekim ve Pazar 10 Ekim 2010. Toplantıların çoğu herkese açık olacaktır. Misafirlerimiz olarak Facebook, Percona ve Intel bizlen olucak.
Ayrıca yerel (İstanbul) kullanıcı grupları ve bizim toplantıya ilgilenlerini arıyoruz. Sizi İstanbul’da görmek üzere, …
Sphinx search is a full text search engine, commonly used with MySQL.
There are some misconceptions about Sphinx and its usage. Following is a list of some of Sphinx’ properties, hoping to answer some common questions.
Sphinx works by reading documents, usually from databases. Considering the case of MySQL, Sphinx issues a SQL query which retrieves relevant data (mostly the text you want to index, but other properties allowed).
The above describes Sphinx as a general fulltext search engine for databases. It does, however, have special treatment for MySQL:
Open Query is now three years old! We initially started with consulting and training services, and extended this with our proactive subscriptions that also offers system administration and monitoring.
So how is it going? Pretty well. We’ve been profitable from the start, without funding (beyond a few hundred $ startup costs paid by Arjen) or any credit – by choice. Our objective has never been to grow ridiculously in terms of revenue or number of customers, we simply charge reasonable prices for real service. Right now we have dozens of clients on an ongoing basis, a neat trickle of new clients, and Open Query sustains the livelyhood and lifestyle of a number of people.
For me (Arjen), the three year mark is particularly interesting, since most startups do not make it past their first two years. With our different approach to doing business, we’ve seen our fair share of skepticism. Not that we mind, if anything it’s encouragement
If you’d like to learn more about our business principles, see the Upstarta site.
Seriously, it did. Sorta.
I use Workbench for my daily work, and it’s a great tool. If you haven’t tried the 5.2 release yet, you should. While performing some maintenance, I happened to issue a DELETE statement against a table which had no indexes (it was 10 rows), and Workbench complained:
Error Code: 1175
You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column
It turns out this is a new feature in 5.2.26 (and is still there in 5.2.27) – Workbench now uses the equivalent of –safe-updates mode for the mysql command-line client (also known as the –i-am-a-dummy option – seriously). This wasn’t exactly convenient for me, especially since the DELETE was part of a larger script which I then had to revise and step through manually after it failed, but there’s an easy way to change this behavior. If you’re like me, you might consider disabling this:
Despite the text, the –safe-updates mode affects more than UPDATE and DELETE statements without WHERE clauses – it requires such statements to explicitly use indexes.
I’m changing this behavior on my installation before I run into other problems.
I’m no dummy.
In database modeling, a m:n relationship is usually resolved by an additional table. But what if this relation is used only for archiving and the number of links in the resulting table is not too high? In that context, I got the idea to store all referring ID's as CSV string directly into a TEXT column of one of the referring tables. I came to this idea, because otherwise I would have to build complicated foreign keys and this way I also save one additional table. Certainly, this only makes sense if the data is not frequently accessed as foreign key. Nevertheless, I would like to tackle the problem, even if the implementation is very MySQL-oriented.
“Hey DBA! Remember that change you made for my group four or five months ago? Well, we were waiting for things to get better but they have not. Can you change it back ASAP?!?”
I know several of you DBAs after reading the above are reaching for their antacids. OR something stronger.
Keeping track of what changes were made to which systems in your head is bound to bite a hard working DBA sooner or later.
This is one of those oh-so-obvious tips that will be ignored by many but it will come back to haunt like a cheap RAID array. Get a notebook, a pen, and keep it by you when you work. Now anytime you make a material change or perform a maintenance function on one of your systems, note what EXACTLY the change you made, the reason for the change, plus the day and date. It will take some effort to do this the first two times but you this to become an ingrained habit. Keeping track of running myisamcheck, changing the IP address of a replication slave, or setting up a MyIsam buffer cache is tedious but it will pay off when you are assailed with something similar to the sentence that starts this entry.
And for those of us with poor rotten hand writing — take the effort to make it legible. You may need to read it at 3AM after twenty hours of fighting a problem. Or the poor person covering for you while you are on vacation can not tell if you changed max_connections or max_connect_errors and decides to set them both to zero.
So why not store this data electronically? Well, Murphy’s Law aside, it is very handy to have something to refer to that is portable, does not need electrons to read, and is based on a technology even the most pointy haired boss can understand.
And it helps to have a print out of your my.cnfs taped into the back of the notebook.
Here are the last two entries in my log.
Not much new this time: just summary of part 3 published and fixed mistake in chapter 10 (thanks, Shane!).
Summary.
In the third part we discussed methods of application debugging in cases when query plays secondary role in the problem.
I'd like to bring your attention we only discussed most frequent cases while MySQL server has a lot of parameters which of them can affect application. Analyze parameters which you use. One of the methods is run problematic query using MySQL server running with option --no-defaults and examine if results are different for MySQL server run with parameter which you use. If results are different analyze why parameter affects it and solve the problem.
Rest of the chapter is here.
最近评论
5 天 4 小时 前
5 天 11 小时 前
1 周 5 天 前
2 周 6 小时 前
3 周 1 天 前
3 周 5 天 前
3 周 5 天 前