That’s right, myself and three others flew over to Anaheim, California to the Anaheim Convention Center for Blizzard’s 3rd Annual BlizzCon! This year Blizzard featured all three of its games at the Con: World of Warcraft, Starcraft and Diablo. I decided that despite the embarrassment which I might endure, I would dress up as a Blood Elf, featured in Blizzard’s World of Warcraft: The Burning Crusade. I was a bit nervous at first. While approaching the convention center I saw no one dressed up in costume in sight, and there I was, sporting these ridiculous elf ears. Once I entered the convention center I was astounded. About 40% of the 15,000 people who showed up for the convention were dressed up in the most elaborate outfits. From bulked up Horde warlocks to Alliance elves skimpy bikinis, it was all there. Our goodie bags were amazing too! Filled to the brim with fun swag, including a blow up Frostmourne, keychains, Starcraft “Zerg Creep”, Diablo III stress balls, BlizzCon hand sanitizer, mints, Warcraft trading card game starter kit, bottle opener, n00b tissues, paper WoW masks, Starcraft II beta key, polar bear mount for WoW, mouse pads, and these nifty Blizzard Digipass Authenticator by Vasco!
Tickets to Blizzcon were about $100, which was pretty good considering everything at the Con other than food was free. They had free pictures with a background of the game of your choice. You can view more of these photo’s at www.politeinpublic.com Someone actually proposed in one of the photos - and don’t worry, she said yes!
During many of the developer panels - where they explained the new game World of Warcraft: Wrath of the Lich King - I was texting our lead QA pro Dave Loya of all of the awesome new details for the new unveiled class, The Death Knight. The Con also had several computer set-ups for participants to play Starcraft II, World of Warcraft: Wrath of the Lich King and Diablo III. I ended up demoing Diablo III, and it truly looks fantastic! They have some more work to do on the game, but they did unveil a new class as well, the Wizard!
The Con itself was a sight to see. There were meet and greets galore! Participants had the opportunity to meet with Blizzard employees and obtain free swag such as professional pictures, figure prints, trading cards and so much more! We all waited in line for about two hours to get plush Murocs, which Jinx was all sold out by 6 p.m the first evening. I tried to get pictures of everyone that were dressed up, I even found a few fellow Blood Elves! My crew was very recognizable due to the fact that we were all wearing red matching Tabards. They are a exact replica of our guild tabards in game which are The Bloodrocutioners. Chelsea (Designer, 1st Playable Productions) made all of the Tabards worn at the Con all on her own with some sewing help from our other friends who came along for the trip. The painstaking work totally paid off as people were shouting “Look! Guildies!” and snapping pictures in our faces. I think we averaged about 150 photos taken of us by random people per day. By 10p.m. both nights I was seeing spots. I couldn’t believe that if you were dressed up, you were photographed like a celebrity. I even had one kid ask us to sign his Warcraft book with our names, realm name and guild name. There were also many gals paid by Blizzard to model official WoW costumes! Also, My crew and myself were interviewed my two different websites!
The final night had a great concert by Level 80 Elite Tauren Chieftain, which is Blizzards metal band. Even the CEO was in the band! The Orchestra concluded the evening with powerful music from Warcraft, Starcraft and Diablo. The theme music from World of Warcraft I must say, did give me goosebumps. I encourage anyone who plays any of the Blizzard games to check out the next Con in 2009, because I know I will be there! It was an amazing time and so surreal with the ambience of gaming and fantasy combined into two fun filled days which was BlizzCon 2008!
Our VP of Sales, Peter Ryan is famous! Well, maybe not, but we’re proud of his post on Gamasutra. Check it out here:
Sometimes, things go wrong.
Sometimes, things go horribly, horribly wrong, and there’s nothing you can do to stop the slow-motion train wreck unfolding before your very eyes. (Like that one senior prom where you spilled your dinner all over your date’s dress. On the upside, you didn’t need that $200 anyway.) When things go that awry, there’s no way to fix it. (She never did return your phone calls, did she?) The only thing you can do with a mistake like that is to make sure it never, ever happens again.
For most of the sites we produce, we use MySQL as a backend. While it’s extremely rare for the MySQL server to catastrophically fail, it happens, and the more MySQL servers you have, the more likely it is to happen at least once. To keep this from causing problems for us, we replicate our databases (that is, maintain a live copy of them). This provides us with two benefits:
So, let me walk you through setting up a database slave from scratch.
I am starting with two identical machines that are running identical instances of MySQL. The first of these, Dragon, is going to be the master. The second of these, Unicorn, is going to be the slave. (So I name my servers after mythical beasts. What’s wrong with that?) I am assuming a reasonable level of knowledge with the UNIX shell. If you lack familiarity, you really should spend some time learning. It will make you a better programmer, system administrator, friend, spouse, and human being.
1. First, you should have the following items set in your MySQL configuration (/etc/mysql/my.cnf). If you don’t, add them: they can go anywhere under the [mysqld] heading.
server-id = 1 log-bin = /var/lib/mysql/binlog/mysql-bin expire_logs_days = 1 max_binlog_size = 100M relay_log = /var/lib/mysql/binlog/mysqld-relay-bin relay_log_index = /var/lib/mysql/binlog/mysqld-relay-bin.index
The server-id should be some unique number, not shared with any other machine on your network. Replication occurs by copying around binary log files; you should set expirelogsdays so that you don’t end up with a huge pileup of data clogging up your disk drives (as they will eventually eat up your hard disk). We set binary logs to expire after 1 day, since our disks have a tendency to fill up on us quickly (for example, one of our Guitar Hero master databases has a 6GB binary log directory, even though it expires data after a single day!) Be advised that if you are worried about your slaves falling more than a day behind, you should keep logs around for a greater duration. (However, from our experience, if your slaves fall more than a day behind, you have bigger problems.) Finally, you can put datadir, relay_log, and relay_log_index wherever you please; above are just where we use. (Make sure, however, that they exist and are writable by the mysql user!)
You should restart the server after changing the settings. On Debian and Ubuntu, you can do this via “/etc/init.d/mysql restart”.
2. Your slave should have the same options defined as above in its MySQL configuration. The server-id option, however, must be different from the master (in our case, setting it to “2” will do). All the other options can be whatever you please.
Also restart this server when it’s set as you like.
3. You should grant permission for the slave to read data from the master. This can be done from the MySQL console on the master (mysql -h dragon -u root). Assuming the user name “foo” and the password “bar”:
mysql> GRANT REPLICATION SLAVE ON \*.\* TO 'foo'@'unicorn' IDENTIFIED BY 'bar';
You can, of course, restrict which databases and tables you grant permissions with. We don’t in this particular case.
4. You now need to dump all of the data on the master, copy it over to the slave, and import it there; this is necessary even if your databases are empty, as it will initialize the slave regardless.
On the master (this will require your MySQL root password):
mysqldump -uroot -p --all-databases --single-transaction --master-data=1 | gzip >master.sql.gz
If you don’t have a root password (which is generally a bad idea, but fine if your MySQL server is on a private network), you should omit the
You can copy this file over to the slave server using
scp master.sql.gz unicorn:
Finally, import the dump on the slave:
zcat master.sql.gz | mysql -uroot
5. Tell the slave to mirror the master.
mysql> CHANGE MASTER TO MASTER_HOST='dragon', MASTER_USER='foo', MASTER_PASSWORD='bar';
6. Start the slave!
mysql> START SLAVE;
You can now monitor the progress of your slave using
SHOW SLAVE STATUS. (If you use a
\G instead of a semicolon to terminate the line, it will print out the data in a much more readable format.)
mysql> SHOW SLAVE STATUS\G
There could be a number of errors, which are beyond the scope of fixing here. (In my case, we ran into issues with binary logs and the binary log index files.) These can generally be troubleshooted (troubleshot?) by reading the output of syslog (
tail -f /var/log/syslog) and fixing the problem one piece at a time; it helps to have a lot of UNIX experience, though.) If all goes well, though,
SHOW SLAVE STATUS will have lines something like the following:
Slave_IO_State: Waiting for master to send event Master_Host: dragon Master_Port: 3306 Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 12887
This indicates that the slave is running and in the process of catching up to the master, and in time will be synchronized with it.
And, that’s (hopefully!) all there is to it! Now, with your new slave, you can go forth and conquer the world! (Or, less ambitiously, cover your backside when you accidentally delete something.)
Obligatory CTO Note: Make sure you keep, and regularly verify your daily backups too!