O documento descreve um caso de estudo da empresa Ricardo Eletro que precisava aumentar sua capacidade de processamento de queries no banco de dados de 100 mil queries por segundo. A solução proposta foi implementar replicação de dados em quatro servidores com 16GB de memória cada um, otimizando a base de dados e o código para atingir a capacidade desejada de 120 mil queries por segundo com baixo custo e simplicidade.

1. Estudo de Caso: Ricardo Eletro Case: Ricardo Eletro Replicação +100KQPS HTI Consultoria e Tecnologia Alexandre M Almeida alexandre@hti.com.br

3. enfileiramento de “queries”

4. necessidade de aumento da capacidade de entregareflexo direto no faturamento

6. aumentar dramaticamente a capacidade de entrega

7. evitar as paradas nas vendas devido falhas do BD

8. Suportar acima de 100.000 QPS (“queries per second”)

10. Um servidor altamente produtivo atinge mais de 2.500 QPS

11. Não é recomendado ir acima de 5.000 QPS

12. “Mas” existem servidores com mais de 10.000 QPSfatores determinantes: normalização/configuração/código

14. Balanceador de carga

15. Configuração mega-hiper-super-complicada

16. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

18. Replicação

19. Otimização da base dados

20. Localização de “queries mal criadas”

22. Interdependência A x B

23. Alta Disponibilidade

24. Alta Performance

25. Simplicidade (3S)

26. Capacidade: 120K QPS

27. Backup Online

28. CO = Baixo

30. Round Robin (RR DNS)

31. UltraMonkey

32. MySQL Proxy (<= 5K QPS)

34. Normalmente, esta capacidade está muito aquém do HW

35. Não adianta reservar altos níveis de buffers & caches

36. Característica “Multi-Threaded”

37. O instanciamento visa maximizar e otimizar o uso do HW(mas, precisa ter HW!!!!)

39. Normalização do banco de dados (melhorar a concorrência)

40. Índices – no final das contas, eles salvam o dia

41. Criação de tabelas sumarizadas para relatórios pesados

42. Entender os pontos onde podem haver “racecondition”

44. Rede “apertada” (não geo!)

46. Sincronismo ( precisar ser monitorado )

47. Distância entre servidores “seconds behind master”

49. Analise se “Query Cache” está ajudando ou atrapalhando

50. Excesso de threads com “invalidating query cache” ou “freeing items”

51. Monitores as váriaves de estado “QC%”

52. Se for arrojado!!! Usar 1 base para cada duas ou mais instâncias:

53. sistema de arquivos preparado para “shared disk” (GFS, QFS, OCFS, etc)

54. só MyISAM

56. --auto-increment-increment

57. --auto-increment-offset

58. Não deixe os slaves ultrapassar 5K QPS

59. Faça manutenções periodicamente e localmente