Que pouvons-nous faire dans MySQL 5.0 réplication à des problèmes de bande passante d'adresse?

Question

Je développe une application à exécuter sur le PC client (Win) qui est configuré avec un serveur MySQL 5.1 par exemple qui agira comme esclave en lecture seule au maître à distance. Le maître à distance a des dizaines de schémas, mais je besoin d'un seul par client, donc je fournir le réglage réplication-do-db dans my.ini seulement reproduire le schéma que les besoins des clients. Les travaux de réplication, mais quand nos clients entrent dans les régions du monde où l'accès à Internet est disponible uniquement via 3G sans fil, qui la charge par l'utilisation des données, ils dépassent rapidement leurs limites du plan de données et le fonctionnement des problèmes coûteux.

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

Pour réduire cette inefficacité j'ai employé slave_compressed_protocol = 1 réglage, ce qui semble réduire les données transmises par 50%, mais cause de notre client à dépasser rapidement leur limite de données en rack la facture 3G .

Je ne peux pas imaginer que je suis le seul face à cela, donc je suis sûr que je vais obtenir une tonne de réponses sur la façon d'y parvenir par le réglage x = y. Cependant, je ne peux trouver aucune documentation de l'établissement d'un tel, ni une approche recommandée à prendre.

Jusqu'à présent, voici ma pensée à une solution possible, s'il vous plaît fournir des commentaires ou des itinéraires de rechange:

---

1. Mise en place d'un esclave pour chaque schéma « proxy » (de boîte différent, ou même boîte avec une autre instance de MySQL / port)
2. Configurer l'esclave proxy pour replicate-do-db seulement une base de données que les clients souhaitent répliquer.
3. Configurer l'instance de MySQL du client comme esclaves à l'esclave proxy approprié.

devrait résultat dans le client ne tirant les données binlog pour leur schéma. L'inconvénient (pour autant que je peux dire) est qu'il augmente considérablement la complexité de notre configuration, ce qui rend probablement plus fragile.

Pensées? Est-ce que cette approche fonctionne même?

Note, nous courons le serveur MySQL 5.0 sur RedHat, mais nous pourrions passer à 5,5 si elle produit une solution.

Answer 1

SUGGESTION # 1: Utiliser Master Distribution

Un maître de distribution est un esclave MySQL avec log-bin activé, les mises à jour-esclaves journaux activés et ne contient que des tables avec BLACKHOLE stockage moteur. Vous pouvez appliquer replicate-do-db au Maître de distribution et créer des journaux binaires au maître de distribution qui ne contient que le schéma DB (s) que vous voulez binlogged. 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 votre base de données (s) en utilisant l'option --no-données pour générer un vidage de schéma uniquement.
2. Charger la décharge de schéma uniquement au Maître de distribution.
3. Convertir toutes les tables dans le Master de distribution au moteur de stockage BLACKHOLE.
4. réplication d'installation au maître de la distribution d'un maître avec des données réelles.
5. Ajouter une option replicate-do-db (s) à /etc/my.cnf du Maître de distribution.

Pour connaître les étapes 2 et 3, vous pouvez également modifier le schéma uniquement vidage et remplacer MOTEUR = MyISAM et InnoDB MOTEUR = avec MOTEUR = BLACKHOLE puis chargez ce schéma uniquement dans le vidage édité maître de distribution.

A l'étape 3 uniquement, si vous voulez le script la conversion de toutes les tables MyISAM et InnoDB à BLACKHOLE dans le Maître de distribution, exécutez la requête suivante et la sortie 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 de la conversion de script de table pour le moteur de stockage est que BLACKHOLE tables de moteur de stockage de mémoire sont convertis aussi bien. Alors que la table de moteur de stockage MEMORY ne prend pas l'espace disque pour le stockage des données, il prendra la mémoire. Conversion de tables de mémoire pour BLACKHOLE gardera la mémoire dans le Master de distribution bien rangé.

Tant que vous n'envoyez pas dans le Maître DDL de distribution, vous pouvez transmettre tout DML (INSERT, UPDATE, DELETE) vous le désirez avant de laisser les clients répliquent que les informations qu'ils veulent DB.

je l'ai déjà écrit un post sur un autre site qui traite de l'utilisation StackExchange un Master de distribution .

SUGGESTION # 2: Utilisez de petits logs, binaire et relais

Si vous définissez max_binlog_size à quelque chose ridiculement petit, puis binlogs peuvent être collectées et expédiées en petits morceaux. Il y a aussi une option séparée pour définir la taille des journaux de relais, max_relay_log_size . Si max_relay_log_size = 0, il sera par défaut à tout ce max_binlog_size est réglé sur.

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

Configuration votre base de données principale et plusieurs maîtres distribution comme MySQL 5.5. Activer la réplication semi-synchrone afin que la base de données principale peut rapidement expédier binlogs au Maître de distribution. Si tous vos esclaves sont maîtres de distribution, vous ne pouvez pas besoin de réplication ou MySQL semi-synchrone 5.5. Si l'un des esclaves, autres que maîtres de distribution, ont des données réelles pour les rapports, la haute disponibilité, veille passive ou à des fins de sauvegarde, puis aller avec MySQL 5.5 en collaboration avec la réplication semi-synchrone.

SUGGESTION # 4: utilisation Déclaration basée sur la journalisation binaire NOT Row-Based

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

Un autre problème utilise RBBL conjointement avec replicate-do-db où le nom de la table a la base de données préfixé . Cela ne peut pas être bon pour un esclave, en particulier pour un Master de distribution. Par conséquent, assurez-vous que tous DML ne dispose pas d'une base de données et une période devant les noms de table.

Answer 2

Le max_binlog_size doit être hors de propos -. Les données sont transmises en continu binlog en permanence

Mise en garde au sujet d'un « Master Distribution » - c'est un « point de défaillance unique ». Autrement dit, si elle meurt, tous les esclaves (s) au-delà ne sera pas recevoir des données, et la reconstruction du relais prendra le travail.

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

Mettre les maîtres de distribution sur la même machine que le vrai maître, ou sur une machine « près » du Maître. Utiliser des ports séparés pour garder les instances distinctes.