Que pouvons-nous faire dans la réplication MySQL 5.0 pour résoudre les problèmes de bande passante?

Je développe une application à exécuter sur le PC client (Win) qui est configurée avec une instance de serveur MySQL 5.1 qui agira comme esclave en lecture seule du maître distant. Le maître distant possède des dizaines de schémas, mais je n'en ai besoin que d'un par client, je fournis donc le paramètre replication-do-db dans my.ini pour répliquer uniquement le schéma dont le client a besoin. La réplication fonctionne, mais lorsque nos clients pénètrent dans des régions du monde où l'accès à Internet n'est disponible que via la technologie sans fil 3G, qui se charge par l'utilisation des données, ils dépassent rapidement les limites de leur plan de données et rencontrent des problèmes coûteux.

Si je comprends bien, MySQL écrit toutes les transactions pour tous les schémas dans un seul fichier binlog, ce qui signifie que chaque client doit télécharger toutes les transactions effectuées sur chaque schéma du maître, puis une fois téléchargé, appliquer le filtre de base de données par réplication - paramètres do-db dans le fichier my.ini du client.

Pour minimiser cette inefficacité, j'ai utilisé le paramètre slave_compressed_protocol = 1 , qui semble réduire les données transmises de 50%, mais qui fait que nos clients dépassent rapidement leur limite de données pour augmenter la facture 3G.

Je ne peux pas imaginer que je suis le seul à y faire face, donc je suis sûr que j'obtiendrai une tonne de réponses sur la façon d'y parvenir en définissant x = y. Cependant, je ne trouve aucune documentation sur un tel paramètre, ni une approche recommandée à adopter.

Jusqu'à présent, voici ma pensée pour une solution possible, veuillez fournir des commentaires ou des itinéraires alternatifs:

1. Configurer un esclave "proxy" pour chaque schéma (sur une boîte différente, ou même boîte avec une instance / un port MySQL différent)
2. Configurez l'esclave proxy pour répliquer-faire-db uniquement la seule base de données que les clients souhaitent répliquer.
3. Configurez l'instance MySQL du client en tant qu'esclaves de l'esclave proxy approprié.

Cela devrait avoir pour conséquence que le client extrait uniquement les données binlog de son schéma. L'inconvénient (pour autant que je sache) est qu'il augmente considérablement la complexité de notre configuration, ce qui la rend probablement plus fragile.

Pensées? Cette approche fonctionnera-t-elle même?

Remarque, nous exécutons le serveur MySQL 5.0 sur RedHat, mais nous pourrions mettre à niveau vers 5.5 s'il produit une solution.

SUGGESTION # 1: Utiliser des maîtres de distribution

Un maître de distribution est un esclave mysql avec la fonction log-bin activée, la fonction log-slave-updates activée et contient uniquement des tables avec le moteur de stockage BLACKHOLE . Vous pouvez appliquer replicate-do-db au maître de distribution et créer des journaux binaires sur le maître de distribution qui contient uniquement le ou les schémas de base de données que vous souhaitez enregistrer en binogue. De cette façon, vous réduisez la taille des binlogs sortants du maître de distribution.

Vous pouvez configurer un maître de distribution comme suit:

1. mysqldump vos bases de données en utilisant l'option --no-data pour générer un vidage de schéma uniquement.
2. Chargez le vidage de schéma uniquement dans le maître de distribution.
3. Convertissez chaque table du Distribution Master en moteur de stockage BLACKHOLE.
4. Configurez la réplication vers le maître de distribution à partir d'un maître avec des données réelles.
5. Ajoutez les options replicate-do-db à /etc/my.cnf du maître de distribution.

Pour les étapes 2 et 3, vous pouvez également modifier le vidage de schéma uniquement et remplacer ENGINE = MyISAM et ENGINE = InnoDB par ENGINE = BLACKHOLE, puis charger ce vidage de schéma modifié uniquement dans le maître de distribution.

À l'étape 3 uniquement, si vous souhaitez créer un script pour la conversion de toutes les tables MyISAM et InnoDB en BLACKHOLE dans le maître de distribution, exécutez la requête suivante et exportez-la dans un fichier texte:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

Un avantage supplémentaire à l'écriture de scripts de conversion de table vers le moteur de stockage BLACKHOLE est que les tables du moteur de stockage MEMORY sont également converties. Bien que la table du moteur de stockage MEMORY n'occupe pas d'espace disque pour le stockage de données, elle occupera de la mémoire. La conversion des tables MEMORY en BLACKHOLE gardera la mémoire dans le maître de distribution épurée.

Tant que vous n'envoyez pas de DDL dans le maître de distribution, vous pouvez transmettre tout DML (INSÉRER, METTRE À JOUR, SUPPRIMER) que vous souhaitez avant de laisser les clients répliquer uniquement les informations de base de données qu'ils souhaitent.

J'ai déjà écrit un article dans un autre site StackExchange qui traite de l'utilisation d'un maître de distribution .

SUGGESTION # 2: Utiliser des journaux binaires et des journaux de relais plus petits

Si vous définissez max_binlog_size sur quelque chose de ridiculement petit, les binlogs peuvent être collectés et expédiés en petits morceaux. Il existe également une option distincte pour définir la taille des journaux de relais, max_relay_log_size . Si max_relay_log_size = 0, il prendra par défaut la valeur max_binlog_size définie.

SUGGESTION # 3: Utiliser la réplication semi-synchrone (MySQL 5.5 uniquement)

Configurez votre base de données principale et plusieurs maîtres de distribution en tant que MySQL 5.5. Activez la réplication semi-synchrone afin que la base de données principale puisse expédier rapidement les journaux de tâches au maître de distribution. Si TOUS vos esclaves sont des maîtres de distribution, vous n'aurez peut-être pas besoin de la réplication semi-synchrone ou de MySQL 5.5. Si l'un des esclaves, à l'exception des maîtres de distribution, possède des données réelles à des fins de génération de rapports, de haute disponibilité, de veille passive ou de sauvegarde, alors utilisez MySQL 5.5 en conjonction avec la réplication semi-synchrone.

SUGGESTION # 4: Utiliser la journalisation binaire basée sur les instructions NON basée sur les lignes

Si une instruction SQL met à jour plusieurs lignes dans une table, la journalisation binaire basée sur les instructions (SBBL) ne stocke que l'instruction SQL. La même instruction SQL utilisant la journalisation binaire basée sur les lignes (RBBL) enregistrera le changement de ligne pour chaque ligne. Cela rend évident que la transmission des instructions SQL permettra d'économiser de l'espace sur les journaux binaires faisant SBBL sur RBBL.

Un autre problème est d'utiliser RBBL en conjonction avec replicate-do-db où le nom de la table a la base de données ajoutée . Cela ne peut pas être bon pour un esclave, en particulier pour un maître de distribution. Par conséquent, assurez-vous que tous les DML n'ont pas de base de données et un point devant les noms de table.

La taille max_binlog_size ne doit pas être pertinente - les données binlog sont diffusées en continu.

Attention à un "maître de distribution" - il s'agit d'un "point de défaillance unique". Autrement dit, s'il meurt, tous les esclaves au-delà ne recevront pas de données, et la reconstruction du relais prendra du travail.

SBR vs RBR - cela dépend de la requête. L'un ou l'autre peut être meilleur ou pire que l'autre.

Placez les maîtres de distribution sur la même machine que le vrai maître, ou sur une machine "près" du maître. Utilisez des ports séparés pour garder les instances séparées.