Comment faire évoluer automatiquement les serveurs MySQL?

8

Je gère un site qui connaît une forte augmentation du trafic et, à cause de cela, les solutions de mise à l'échelle automatique sont très rentables dans ce cas. Actuellement, le serveur Web peut évoluer automatiquement horizontalement, mais le goulot d'étranglement se trouve sur le serveur MySQL.

  • J'ai essayé avec Amazon RDS Multi-AZ mais il faut environ 15 minutes pour que la base de données de 12 Go se mette à niveau avec quelques minutes d'arrêt. Cela m'a beaucoup aidé quand je savais déjà qu'une augmentation du trafic allait se produire à un moment précis.
  • J'ai également considéré Xeround. C'est probablement la meilleure solution bien qu'elle soit assez chère pour des bases de données de cette taille. Quoi qu'il en soit, ce n'est pas une option car j'ai légalement besoin que la base de données se trouve dans l'Union européenne.
  • J'ai lu sur Scalr mais je ne sais pas si cela pourrait être utile et comment.
  • J'ai vu que de nombreux fournisseurs d'hébergement cloud proposent des solutions de mise à l'échelle verticale qui, je pense, n'ont aucun temps d'arrêt (je ne sais pas si c'est vraiment possible, pour autant que je sache, ils utilisent l'hyperviseur Xen). Cela pourrait être une solution, mais je me demande s'il n'y a pas de temps d'arrêt et comment la configuration MySQL (et bien d'autres choses sur le système d'exploitation) peuvent également être mises à niveau sans temps d'arrêt.
  • J'ai essayé avec des serveurs esclaves MySQL mais ce n'était pas du tout utile.
  • J'utilise memcache qui aide beaucoup mais ce n'est pas suffisant. J'ai besoin de mettre à niveau à cause des écritures, pas seulement à cause des lectures.

Aucune suggestion? Merci d'avance

mysql scalability amazon-rds scalr Zillo
la source
semble que vous êtes coincé avec le même problème que moi :( Vous pouvez envisager la réplication multimaître ou essayer d'utiliser une solution de base de données différente pour les tables avec des écritures lourdes. J'évalue actuellement voltdb, j'envisage de déplacer partiellement les tables vers voltdb à la place de MySQL.
Niko SP
Pourriez-vous ajouter plus de détails sur "J'ai essayé avec des serveurs esclaves MySQL mais cela n'a pas été utile du tout". De quelle manière avez-vous changé votre architecture, que vous attendiez-vous à ce qui ne se produise pas?
nickgrim
1
Le logiciel que nous utilisons est déjà conçu pour utiliser des serveurs esclaves MySQL si vous le souhaitez mais malgré cela, cela n'a pas aidé du tout. Je pense que memcache fait presque tout le travail esclave MySQL (la plupart des lectures). Je pense que l'esclave MySQL était plus un problème que quelque chose de positif mais de toute façon cela dépend de chaque cas, probablement dans certains cas il est utile alors que dans d'autres non.
Zillo

Réponses:

4

En fait, une solution plus simple serait d'essayer d'ajouter Memcached à votre pile pour économiser sur la charge de la base de données. Cela peut considérablement économiser de la charge et est beaucoup plus simple que d'essayer de résoudre rapidement le problème de la mise en service des serveurs (faible difficulté), puis de prévoir une synchronisation MySQL rapide (difficulté beaucoup plus élevée).

http://toblender.com/?s=memcached

Pour résoudre le problème d'un trop grand nombre d'écritures, la solution la plus courante consiste à ajouter de la mémoire au serveur (un ensemble de travail plus important peut être conservé dans la RAM), à placer votre base de données sur des disques plus rapides (les SSD sont une bonne solution, mais coûteuse), ou à partager (ce qui coûte cher en serveurs supplémentaires et en complexité).

Une autre façon de réduire la charge d'écriture de la base de données consiste à incorporer un magasin de données en mémoire (tel que Redis) pour gérer les données qui changent fréquemment et, si nécessaire, réécrire périodiquement les modifications dans votre base de données principale.

gWaldo
la source
pourriez-vous donner un exemple de la façon dont memcached aiderait à réduire la charge d'écriture sur les serveurs mysql?
Niko SP
1
Excuses; Je n'ai pas vu cette partie.
gWaldo
Réponse mise à jour pour répondre aux problèmes de latence d'écriture.
gWaldo
Votre suggestion de SSD concerne l'argent, et les SSD ne sont pas nécessairement chers pour une si petite base de données. Même avec une base de données plus importante, ZFS permet de mettre en cache toutes les écritures directement sur la mémoire flash SLC.
Skyhawk
Tu as raison; Les SSD pour une base de données de 12 Go ne sont pas chers du tout. Je pensais plus au cas général qu'aux paramètres spécifiques du PO.
gWaldo
3

Vous devriez envisager d'utiliser une topologie en étoile

Voici ce que je propose

  • One Write Master (alias WM)
  • Un maître de distribution (alias DM)
  • Cinq (5) serveurs esclaves de lecture (aka RSS)

Préparez la topologie comme ceci

Étape 01: Configurer 5 RSS avec ces options courantes

[mysqld]
skip-innodb
key_buffer_size=1G

Cela entraînera la création de toutes les tables chargées en tant que moteur de stockage MyISAM

Étape 02: configuration de DM et de tous les serveurs RS

  • mysqldump le schéma de toutes les tables de WM dans un fichier schemadump
  • charger le fichier schemadump dans DM et tous les 5 RSS
  • exécuter ALTER TABLE tblname ROW_FORMAT=Fixed;sur toutes les tables en RSS
  • exécuter ALTER TABLE tblname ENGINE=BLACKHOLE;sur toutes les tables dans DM
  • données mysqldump uniquement (en utilisant --no-create-info) vers un datadump
  • charger le vidage de données dans les 5 flux RSS

Étape 03: configuration de la réplication de DM vers les 5 flux RSS

Étape 04: configuration de la réplication de WM vers DM

FIN DE LA CONFIGURATION

Voici comment fonctionne votre mécanisme de lecture / écriture

  • Toutes vos écritures (INSERT, UPDATEs, DELETEs) se produisent sur le WM
  • SQL est enregistré dans les journaux binaires du DM (aucune donnée réelle ne réside dans le DM)
  • Chaque RSS est un esclave de lecture pour le DM
  • Toutes vos lectures ont lieu sur le RSS

Maintenant, voici le hic ...

  • Vous utilisez RSS 1-4 pour les lectures initiales
  • Utilisez le 5e RSS pour faire tourner d'autres RSS
    • Vous courez service mysql stopau 5ème RSS
    • Faites tourner un autre RSS
    • Copiez / var / lib / mysql et /etc/my.cnf du 5e RSS dans le nouveau flux RSS
    • Vous courez service mysql stopau 5ème RSS
    • Vous courez service mysql stopau nouveau RSS

Vous pouvez utiliser RSS # 5 pour faire tourner de nouveaux serveurs encore et encore

Sur un sidenote, veuillez ne pas utiliser XEROUND pour WM ou DM car ils ne prennent pas en charge le moteur de stockage InnoDB ou BLACKHOLE.

J'espère que ces idées vous aideront.

RolandoMySQLDBA
la source
1

Si vous utilisez Innodb, vous devriez considérer les multi-maîtres Mysql gérés par Galera . Cela rend la configuration de mysql multi-master plus facile, et devrait vous faciliter la mise à l'échelle automatique "semi".

S'il s'agit d'une application que vous ou votre entreprise écrivez, vous pouvez envisager de passer à une conception fragmentée (partitionnée) pour l'application. Mais le sharding peut devenir compliqué. Voici un lien pour commencer.

Je suppose que vous avez "réglé" les fichiers de configuration mysql, comme dans la mémoire appropriée allouée, etc.

Pas maintenant
la source
1

Est-ce dans un rack que vous contrôlez ou dans le cloud? 12 Go est une très petite base de données par rapport à la taille des disques disponibles. Placez-le sur une matrice RAID1 ou RAID10 de petits SSD SLC et votre latence d'écriture disparaîtra.

Le SSD SLC Intel 311 de 20 Go (120 $ chacun) ferait le travail avec brio.

Si la base de données était plus grande, vous pourriez obtenir des résultats tout aussi spectaculaires en déplaçant votre base de données vers une cible iSCSI sur un serveur SAN ZFS (construit sur du matériel de serveur standard utilisant Nexenta, OpenIndiana, FreeNAS ou autre) et en configurant un miroir de SSD similaires pour votre cache d'écriture ZIL. Dans toutes les circonstances, sauf les plus extraordinaires, Gigabit Ethernet est plus que suffisant pour déplacer le trafic iSCSI de la base de données.

Skyhawk
la source