Avec MySQL, les gens font généralement ce qu'on appelle le sharding basé sur les applications .
En un mot, vous aurez la même structure de base de données sur plusieurs serveurs de base de données. Mais il ne contiendra pas les mêmes données.
Ainsi, par exemple :
Users 1 - 10000: server A
Users 10001 - 20000: server B
Le sharding (bien sûr) n'est pas une technique de sauvegarde, il est destiné à répartir les lectures et les écritures sur un cluster.
Les techniques employées pour fragmenter sont le MySQL-Proxy, par exemple. Ce n'est rien que HScale a inventé, c'est plus ou moins un simple script LUA qui distribue les lectures et les écritures sur différents serveurs backend. Il devrait y avoir beaucoup d'exemples sur la forge MySQL.
Un autre outil (basé sur MySQL Proxy) est SpockProxy . Entièrement adapté au partage. Ils se sont également débarrassés de Lua et ont travaillé sur diverses choses pour le rendre plus rapide que le proxy. Jusqu'à présent, je n'ai testé que SpockProxy, mais je ne l'ai jamais exécuté en production.
Maintenant, en dehors de ces procurations, vous pouvez également vous fragmenter. Requis serait une table maître, par exemple :
-------------------
| userA | server1 |
| userB | server2 |
| userC | server1 |
-------------------
Construisez ensuite vos lectures et écritures vers le serveur. Pas très joli mais ça marche. Le prochain obstacle serait de le rendre plus tolérant aux erreurs. Ainsi, par exemple, server1 , server2 et server3 chacun doit être un petit cluster.
Et enfin, une autre approche intéressante pour partitionner les données et les index entre les serveurs est IDDB . Je ne sais pas s'ils ont déjà publié son code, mais leurs articles de blog donnent de nombreux détails sur ce qu'il fait.
Faites-moi savoir si cela vous aide !
