Estudo de Caso: Ricardo Eletro<br />Case: Ricardo Eletro<br />Replicação +100KQPS<br />HTI Consultoria e Tecnologia<br />A...
Case: Ricardo Eletro<br />Replicação +100KQPS<br />O problema?<br /><ul><li> servidores de banco de dados saturados
 enfileiramento de “queries”
 necessidade de aumento da capacidade de entrega</li></ul>reflexo direto no faturamento<br />
Case: Ricardo Eletro<br />Replicação +100KQPS<br />A solução?<br /><ul><li> eliminar o enfileiramento de “queries”
 aumentar dramaticamente a capacidade de entrega
 evitar as paradas nas vendas devido falhas do BD
 Suportar acima de 100.000 QPS (“queries per second”)
 Custos sob controle!</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Fatos:<br /><ul><li> A grande m...
 Um servidor altamente produtivo atinge mais de 2.500 QPS
 Não é recomendado ir acima de 5.000 QPS
 “Mas” existem servidores com mais de 10.000 QPS</li></ul>fatores determinantes: normalização/configuração/código<br />
Case: Ricardo Eletro<br />Replicação +100KQPS<br />Desenho da Solução:<br /><ul><li> 20 computadores servidores 4xQUAD 64G...
Balanceador de carga
 Configuração mega-hiper-super-complicada
Próximos SlideShares
Carregando em…5
×

Estudo de caso Ricardo Eletro

2.572 visualizações

Publicada em

HTI no Fórum da Comunidade MySQL

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.572
No SlideShare
0
A partir de incorporações
0
Número de incorporações
29
Ações
Compartilhamentos
0
Downloads
42
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Estudo de caso Ricardo Eletro

  1. 1. Estudo de Caso: Ricardo Eletro<br />Case: Ricardo Eletro<br />Replicação +100KQPS<br />HTI Consultoria e Tecnologia<br />Alexandre M Almeida<br />alexandre@hti.com.br<br />
  2. 2. Case: Ricardo Eletro<br />Replicação +100KQPS<br />O problema?<br /><ul><li> servidores de banco de dados saturados
  3. 3. enfileiramento de “queries”
  4. 4. necessidade de aumento da capacidade de entrega</li></ul>reflexo direto no faturamento<br />
  5. 5. Case: Ricardo Eletro<br />Replicação +100KQPS<br />A solução?<br /><ul><li> eliminar o enfileiramento de “queries”
  6. 6. aumentar dramaticamente a capacidade de entrega
  7. 7. evitar as paradas nas vendas devido falhas do BD
  8. 8. Suportar acima de 100.000 QPS (“queries per second”)
  9. 9. Custos sob controle!</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Fatos:<br /><ul><li> A grande maioria dos servidores tem menos de 1.000 QPS
  10. 10. Um servidor altamente produtivo atinge mais de 2.500 QPS
  11. 11. Não é recomendado ir acima de 5.000 QPS
  12. 12. “Mas” existem servidores com mais de 10.000 QPS</li></ul>fatores determinantes: normalização/configuração/código<br />
  13. 13. Case: Ricardo Eletro<br />Replicação +100KQPS<br />Desenho da Solução:<br /><ul><li> 20 computadores servidores 4xQUAD 64GB Rede Giga
  14. 14. Balanceador de carga
  15. 15. Configuração mega-hiper-super-complicada
  16. 16. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
  17. 17. Passamos o resto do ano tentando subir a operação</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Desenho da Solução:<br /><ul><li> 04 Servidores 2xQUAD 16GB
  18. 18. Replicação
  19. 19. Otimização da base dados
  20. 20. Localização de “queries mal criadas”
  21. 21. Pequena adequação do código</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br /><ul><li> 04 Servidores 2xQUAD 16GB
  22. 22. Interdependência A x B
  23. 23. Alta Disponibilidade
  24. 24. Alta Performance
  25. 25. Simplicidade (3S)
  26. 26. Capacidade: 120K QPS
  27. 27. Backup Online
  28. 28. CO = Baixo
  29. 29. Dificuldade: 2/5</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />solução mais tradicional<br /><ul><li> Balanceamento via
  30. 30. Round Robin (RR DNS)
  31. 31. UltraMonkey
  32. 32. MySQL Proxy (<= 5K QPS)
  33. 33. MMM for MySQL</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Por quê “instanciar”?<br /><ul><li> O servidor “mysqld” tem capacidade limitada de gestão
  34. 34. Normalmente, esta capacidade está muito aquém do HW
  35. 35. Não adianta reservar altos níveis de buffers & caches
  36. 36. Característica “Multi-Threaded”
  37. 37. O instanciamento visa maximizar e otimizar o uso do HW</li></ul>(mas, precisa ter HW!!!!)<br />
  38. 38. Case: Ricardo Eletro<br />Replicação +100KQPS<br />Preparação 1/2<br /><ul><li> Identificação das “queries” mais pesadas e problemáticas
  39. 39. Normalização do banco de dados (melhorar a concorrência)
  40. 40. Índices – no final das contas, eles salvam o dia
  41. 41. Criação de tabelas sumarizadas para relatórios pesados
  42. 42. Entender os pontos onde podem haver “racecondition”
  43. 43. Preparar a aplicação para ler/escrever em múltiplos pontos</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Preparação 2/2<br /><ul><li> Dimensionar HW versus Instâncias (capacidade total)
  44. 44. Rede “apertada” (não geo!)
  45. 45. Acender 1 vela para cada instância x qtde de tabelas ^ 2</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Desafios<br /><ul><li> Tendência a não seguir e/ou acreditar na preparação
  46. 46. Sincronismo ( precisar ser monitorado )
  47. 47. Distância entre servidores “seconds behind master”
  48. 48. diretamente ligada à rede, dimensionamento, excesso de “queries”</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Dicas 1/2<br /><ul><li> Se possível: InnoDB nos Masters e MyISAM nos Slaves
  49. 49. Analise se “Query Cache” está ajudando ou atrapalhando
  50. 50. Excesso de threads com “invalidating query cache” ou “freeing items”
  51. 51. Monitores as váriaves de estado “QC%”
  52. 52. Se for arrojado!!! Usar 1 base para cada duas ou mais instâncias:
  53. 53. sistema de arquivos preparado para “shared disk” (GFS, QFS, OCFS, etc)
  54. 54. só MyISAM
  55. 55. --external-locking, --delay-key-write=0, --query-cache-type=0 </li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />Dicas 2/2<br /><ul><li> Para escrever, simultâneamente, nos Masters:
  56. 56. --auto-increment-increment
  57. 57. --auto-increment-offset
  58. 58. Não deixe os slaves ultrapassar 5K QPS
  59. 59. Faça manutenções periodicamente e localmente
  60. 60. Seja obstinado na busca por “queries mal criadas”</li></li></ul><li>Case: Ricardo Eletro<br />Replicação +100KQPS<br />e se o tempo permitir…<br />Dúvidas? Comentários? <br />Obrigado!<br />Alexandre & Sakila<br />alexandre@hti.com.br<br />

×