beer planet » hint

2 Gmail Tricks I Bet You Didn't Know About

Artem Russakovskii — Mon, 17 Aug 2009 17:00:00 +0000

OK, maybe you did know them – just see for yourself.

Introduction

The tricks I am going to describe allow you to create unique gmail addresses that still hit your existing gmail inbox, without actually making new gmail accounts.

This can be useful in a variety of situations when you need to use multiple email addresses without having the pain of maintaining them, such as

using unique emails while registering for the same service more than once (say, paypal)
giving out a unique email address to see if you start getting spam to it later – that way you know exactly who to blame for it
more generally, easily create email rules to sort incoming emails into folders, delete them, mark as important, etc.

The hints are not new by any means but it seems like most gmail users are not aware of them. So, without further ado:

Gmail Ignores Dots In Gmail Addresses

Did you know this? I sure didn't, until today, when I read a blog post by a fellow Russian blogger streetmakarov. Apparently, gmail completely ignores dots, so you can insert them anywhere you want in your email address.

Thus, foo.bar@gmail.com is the same as foobar@gmail.com, which is the same as f.o.o.b.a.r@gmail.com, etc – they will all arrive in the same inbox.

This begs the question – what if I registered foo.bar@gmail.com while someone else already owns foobar@gmail.com? Well, some digg and arstechnica users got their panties in a bunch over this a while ago, just to realize that gmail doesn't allow registering accounts that would clash in any way – so if I already own foobar@gmail.com, nobody can register foo.bar@gmail.com or any other combination.

You Can Append a "+ANYTHINGYOUWANT" To Your Username

I think this trick is even more awesome and flexible than the previous one. If your email is foobar@gmail.com, then you can use foobar+blabla@gmail.com, foobar+monkeybananas@gmail.com, etc and those will still land in your original inbox.

This makes it even easier to track the addresses you give out. For example, when I register new twitter accounts, I enter my email as myrealemail+mynewtwittername@gmail.com and then set up a filter in Outlook to filter those out to a separate folder. Simple, painless, and effective.

The only downside to this method is some sites foolishly (or purposely) disallow plus signs in email addresses. Oh well, you can use trick #1 for those.

Conclusion

Do you know other tricks related to "uniquefying" your gmail address? Feel free to share in the comments.

MySQL Slave Lag (Delay) Explained And 7 Ways To Battle It

Artem Russakovskii — Fri, 05 Sep 2008 17:00:40 +0000

Slave delay can be a nightmare. I battle it every day and know plenty of people who curse the serialization problem of replication. For those who are not familiar with it, replication on MySQL slaves runs commands in series – one by one, while the master may run them in parallel. This fact usually causes bottlenecks. Consider these 2 examples:

Between 1 and 100 UPDATE queries are constantly running on the master in parallel. If the slave IO is only fast enough to handle 50 of them without lagging, as soon as 51 start running, the slaves starts to lag.
A more common problem is when one query takes an hour to run (let's say, it's an UPDATE with a big WHERE clause that doesn't use an index). In this case, the query runs on the master for an hour, which isn't a big problem because it doesn't block other queries. However, when the query moves over to the slaves, all of them start to lag because it plugs up the single replication thread.

Sidenote: when I hear an argument that a master has to be the most powerful machine in the group, I cringe at the logic.

If the master can crunch more INSERTs/UPDATEs after an upgrade to a better machine, then replication will fall behind even faster.

There is nothing you can do right now to fix the way MySQL handles replication. If the replication threads could run in parallel, I'm guessing horrible things would happen to the data integrity due to race conditions, canceled queries, slave restarts, differences in query execution times due to server load and configuration, etc. Replication is already an asynchronous, prone to getting out of sync business (hint: use maatkit tools by Baron Schwartz and specifically mk-table-checksum and mk-table-sync to sync up your slaves).

In order to see if a slave is lagging, execute the 'show slave status' command and look for the Seconds_Behind_Master value. The way this value is calculated can be slightly ambiguous and unclear, so I'll explain. It is simply a difference between the 2 timestamps – the time of the last received (and queued up in the relay log) query that already executed on the master and the time of the currently executing query on the slave. Thus this value is not real time (it is possible to catch up to the master much faster); it's an approximation, or special metrics if you will, that helps point out problems.

So what can you do if you start hitting replication lag? This is the ultimate question, and the answer depends on your application. Here are the things I came up with after dealing with MySQL for a few years (there are undoubtedly other techniques, but these all come from my own experience):

Normalize your data, if it is not already. Non-normalized tables lead to repetition and is generally considered bad practice. More data – more IO in most cases. There can be cases, however, where you can normalize too much. Having JOINs is much slower than not having them, and it can hurt your queries if you JOIN a lot. Finally, the extreme case is mentioned at highscalability.com: How I Learned to Stop Worrying and Love Using a Lot of Disk Space to Scale. "You–pause for dramatic effect–duplicate data instead of normalize it. *shudder*". Flickr is provided as an example.
Shard (meaning, slice) your data, horizontally and vertically. For example, you can horizontally partition by some sort of key, hash, username, or other properties. You can also partition vertically by moving out some table columns into other databases. As an example, if you had a database of videos, storing view counts, number of favorites, etc. is OK but if these fields receive a lot of frequent updates, you are bound to have slave lag. Instead, separate these into a dedicated stats table(s). You don't have to shard all of your data – even sharding the most active bits helps immensely (for example, you can choose to shard your stats tables and leave the main one alone).
Upgrade machines running MySQL (first slaves, then master, for the reasons given above). 99% of the time, disk IO is the bottleneck, CPU being the other 1%. Move to RAIDed setups (RAID10 or RAID0) with 6-10 15K RPM SCSI or SSD drives. Add a lot of RAM. Make sure you're running a 64 bit OS if you have more than 3GB of RAM, so that the mysql process may utilize more of it. My search for the best MySQL server under $10K may be of some help here.
Separate your applications onto different MySQL instances. If you are running separate applications A, B, and C that don't depend on each other, consider giving them their own machines, otherwise a single long-running UPDATE or INSERT query in application A will delay all writes by application B and C. This is actually quite common – even though the server may not appear to be loaded, the annoying slave delay will still show its cowardly tail. I want to highlight this again: the replication thread is shared between all databases on the server.
Another solution to (4) is multiple MySQL instances, granted that the MySQL machine isn't generally overloaded already. In that case, installing more than 1 mysql daemons would separate replication threads and allow running multiple applications, like A, B, and C on one machine, without affecting each other. MySQL sandbox achieves just that – it is my preferred solution.
Split up longer running queries into shorter ones. This should be pretty straightforward – a single query on 10 million rows may run a few hours. Splitting it into batches of 50,000, for example, will give other queries a chance to run in between. Of course, you should take care of data integrity and generally double check what you are doing.
Don't overload the same slave by sending all queries to it, as it will just make the matter worse. You can round-robin the queries using either round-robin DNS (eww), round-robin within the application logic (better), smarter application logic, like checking slave load and status from time to time, or my personal favorite – using MySQL proxy and having it pick the least lagging slave for you. An official solution utilizing mysql proxy, called MySQL load balancer, is apparently in the works (I was promised beta access but haven't got it so far).

As a bonus, I wanted to throw in this idea of helping minimize a certain corner case cause of slave delay and feed it to the hungry MySQL minds. I'm not sure if it is mentioned anywhere else, as I have not Googled it. If it's a widely known fact, then I will consider this post as just adding my vote to the usefulness of the technique.

Tip: If you have replication setups that use a lot of INSERT commands and you expect that most of such INSERTs would dupe with existing data (and you are using INSERT IGNORE, not REPLACE), consider replacing such queries with SELECTs, followed by only necessary INSERTs.

The reasoning is simple: INSERTs propagate to all the slaves and have to run on a master. SELECTs can run on any slave and don't propagate anywhere, so if only 0.01% of the queries result in new rows, this technique will get rid of a lot of unnecessary slave query traffic.

Well, there you have it. Comments are open, so feel free to share your own replication strategies and thoughts about mine.

Get advantage of our latest 642-983 exam products and pass your 1Y0-A05 as well as 642-383 exam on first try.

Getting The Most Out Of The MySQL Conference

Artem Russakovskii — Wed, 26 Mar 2008 21:22:24 +0000

As half of the world population already knows, the MySQL conference is coming in less than 3 weeks. Since this event only happens once a year, lasts only 4 days, and costs more than a Russian mail-order bride, I'd really like to get the most out of it. Considering that the schedule is completely packed, with 8 (!!) events going on in parallel, I imagine things can get a little frantic. Additionally, I've never been to a conference of such size before and I'm not sure what to expect.

So… I'm contemplating:

printing out the event schedule and drawing a zig-zagging "map" of exactly where I'll be jumping to next, once the previous presentation ends. I'm actually wondering if I'll need to figure out where all the events are located exactly in advance. How big is that place? Did Google invent in-building walking maps yet? Do people normally jump from one presentation to another parallel one or is that unheard of?

bringing a laptop to take notes. I find it that my brain tends to retain mostly the general ideas for a good period of time. Code details and specifics tend to flush a lot sooner. Keeping notes (and publishing them online) is the best way to retain all this tasty information. Learn it and starting doing it, don't be lazy. For my note taking application, I actually prefer Microsoft (:gasp:) OneNote. It keeps things organized and has a coupe of neat tricks up its sleeve, like built-in OCR, Win-S shortcut for a quick area-defined screenshot, integration with Outlook, audio note-taking. Aha!..

recording audio at every presentation, is that allowed?

getting plenty of sleep the night before each conference day, as the amount of information is going to be simply crushing. I guess I'm going to have to postpone my 3am sessions until Friday or so.

bribing an organ thief to steal Peter Zaitsev's brain and replace it with a statistical computer chip capable of running 17 billion MySQL benchmarks a second. Nobody is going to notice the difference anyway.

Do you have any tips? How do YOU handle conferences? Please share in the comments.