Scaling MySQL - Up or Out?

Sem dúvida nenhuma o melhor Keynote no MySQL Conf, foi o keynote com os representantes de alguns big players da internet, que responderam a várias perguntas relacionadas aos seus ambientes com que diz respeito ao MySQL, entre eles Facebook e Youtube. Só não publiquei antes esse material, pois tive que garimpar essa info por ai até achar o blog do cara que estava digitando em real time todo o debate.

Segue abaixo o resumo dos números, que por sinal são MUITO interessantes:

Moderador do painel: Kaj Arno
Lista dos participantes ordenada pelo Alexa ranking:
1317. Monty Taylor (MySQL)
905. Matt Ingerenthron (Sun)
39. John Allspaw (Flickr)
13. Farhan Mashraqi (Fotolog)
9. Domas Mituzas (Wkipedia)
6. Jeff Rotheschild (Facebook)
2. Paul Tuckfield (YouTube)
p.s.: 3 entre os top 10 do Alexa.

Tabelão com as perguntas e respostas dos participantes:

  How many servers Number of DBAs How many web servers Number of caching servers Version of MySQL Language, platform Operating System
MySQL 1 M, 3 S 1/10 2 2 5.1.23 Perl,php and bash Linux fedora
Sun 2 clustered, 2 individual 1.5 160+ 8 5.0.21 Lots of stuff (java mostly) Open Solaris
Flickr 166 At present 0 244 14 5.0.51 Php and some Java Linux
Fotolog 140 databases on 37 instances 10 instances a DBA 70 40 ( 2 on each, 80 total) 4.11 and 4.4 Php, 90% Java Solaris 10
Wikipedia 20 None, but everybody is kind of a DBA 70+200 40 ( 2 on each, 80 total) Â Php, c++, python Fedora / Ubuntu
Facebook 30000 databases, 1800 db servers 2 1200 805 5.0.44 with relay log corruption patch Php, python, c++ and erlang Fedora / RHEL
Youtube I can not say 3 I can not say I can not say 5.0.24 Python SuSE 9

Mais algumas perguntas extras interessantes:

Number of times re-architected ?

  • MySQL: 2 - 1 time slave, 1 time memcached
  • Sun: site depend (many times over the year)
  • Flickr: Ummm…2.5 (various clusters federated)
  • Fotolog: many cached replacements (about to do one change now)
  • Wiped: Never (Spaghetti)
  • Facebook: Every Tuesday, continual
  • Youtube: Pretty continual, 2-3 times (replication, sharding, federation)

What happens if server fails ? what actions you will generally take ..

  • Flickr: All of our 7 are federated, pairs of servers, we can loose any one side of shard, we can loose boxes.. traffic goes to either side of shard, now it goes to one, and we will get another one (very transparent to user) .. for offline, sites are affected
  • Wikipedia: Users shout at them on IRC then they moderate fixed in seconds
  • Facebook: one of 1800-1900 will always fail, just operate well, minor impact, with data going away for a while…we restore from binlog and start the server quickly, promote slave to master and number of ways
  • Fotolog: we simply mount the snapshots to different servers and get
  • Youtube: SAN etc, very important data.. recover the server, mirrored disk …mirrored hard drive is crucial

Any recommendation of scaling technology that you wanted to bring

  • Fotolog: UltraSPARC-T1 (excellent master, multi threaded) and UltraSPARC-T2 for slave (single threaded)
  • Wikipedia: good n/w switch
  • Facebook: cheap switch, we dont use SAN, neatly partitioned, they scale independently and fail independently
  • MySQL: cluster very sad

Server virtualization ?

  • nobody uses at this time
  • ETL cluster, we may run more than one in the future (facebook)

Anything to worry at present ?

  • Facebook: app design is the key to use resources, data center power supply and consumption
  • Fotolog: Google has to approve it for our power (cut app servers by 1/2 by moving from php to java)
  • Youtube: not at all

Any reco, lessons to DBA

  • better you know what the systems are, then you can
  • performance, scaling taking it serious
  • nothing more permanent than temp solutions (if u don’t know when u will fail, then u will )
  • architect properly in start, schema, cost of serving data
  • 10 mts biggest architectural change
  • memory, resource

Essa foi a integra completa do painel, as respostas estão escritas como foram faladas pelos participantes.

Posso dizer que esse foi um belo resumo prático do que pudemos ver na conferência. Isso também nos dá uma visão muito mais real do uso do MySQL em outras empresas ao redor do mundo.

that’s all folks.

One Response to “Scaling MySQL - Up or Out?”

  1. Camila Says:

    ótimo post !! (eu tava procurando esse resumo :) )
    Vale ressaltar a última parte , a das recomendações!!

Leave a Reply