Quel est le but de MySQL BLACKHOLE Moteur?

Supposons que vous avez deux ordinateurs, chacun exécutant un serveur MySQL. Un ordinateur héberge la base de données primaire, et le second ordinateur héberge un la réplication de l'esclave que vous utiliser comme une sauvegarde.

En outre, supposons que votre serveur principal contient quelques tables ou bases de données que vous ne voulez pas sauvegarder. Peut-être qu'ils sont à haut taux de désabonnement tables de cache et il n'a pas d'importance si vous perdez de leur contenu. Donc, pour économiser de l'espace disque et d'éviter inutile d'utilisation de la CPU, de la mémoire et des disques durs, vous utilisez le les options de réplication pour configurer l'esclave à ignorer les déclarations qui influent sur les tables que vous ne voulez pas sauvegardés.

Mais depuis la réplication uniquement des filtres appliquée sur le serveur esclave, les binlogs pour tous instructions exécutées sur le serveur de base doivent encore être transmis sur le réseau. Il y a de la bande passante gaspillée ici; le serveur maître est l'envoi de binlogs pour les opérations que l'esclave est tout simplement de jeter lors de la réception. Peut-on faire de mieux, et éviter l'inutile utilisation de la bande passante?

Oui, nous le pouvons, et c'est là que le BLACKHOLE moteur est livré dans. Sur le même ordinateur que le serveur maître est en cours d'exécution, nous avons exécuté une seconde, le mannequin mysqld processus, celui de l'hébergement d'un BLACKHOLE base de données. Nous configurer ce mannequin processus de répliquer à partir de la maîtrise du processus de binlog, avec les mêmes options de réplication comme le véritable esclave, et pour produire un binlog de son propre. Le mannequin du processus binlog ne contient les déclarations que le véritable esclave a besoin, et il n'a pas fait tout un travail réel au-delà de filtrer les indésirables consolidés à partir de la binlog (puisque c'est à l'aide de la BLACKHOLE moteur). Enfin, nous allons configurer le véritable serviteur de répliquer à partir de la maquette du processus binlog, plutôt que de l'original de la maîtrise du processus de binlog. Nous avons éliminé l'inutile trafic réseau entre deux ordinateurs qui hébergent les serveurs maîtres et esclaves.

Cette configuration est ce qui est décrit et illustré (beaucoup plus sèchement) par le présent paragraphe et le diagramme de le BLACKHOLE docs:

Supposons que votre application nécessite l'esclave du côté des règles de filtrage, mais le transfert de tous les log binaire de données à l'esclave premiers résultats dans trop de trafic. Dans un tel cas, il est possible de mettre en place sur l'hôte maître un “dummy” esclave processus dont le moteur de stockage par défaut est BLACKHOLE, représenté comme suit:

En plus de filtrage, les docs aussi sibylline soupçon que l'utilisation d'un BLACKHOLE serveur avec binlogging activé "peut être utile comme un répéteur ... mécanisme de". Ce cas d'utilisation est étoffé moins dans les docs, mais il est possible d'imaginer un scénario dans lequel ce serait logique. Par exemple, supposons que vous avez beaucoup de serveurs esclaves, sur tous les ordinateurs sur un réseau local avec local rapide des connexions les uns aux autres, et qui ont besoin de reproduire de grandes quantités de données à distance à partir d'un esclave qui ne peut être connecté sur internet. Vous ne voulez pas de les avoir tous répliquer directement à partir de la boîte principale, depuis lors, vous obtenez les mêmes données à plusieurs reprises, et à l'aide de plusieurs fois plus de bande passante internet que vous devez. Mais supposons que vous aussi ne voulez pas avoir juste un de vos esclaves répliquer à partir de le maître et les autres répliqués que les esclaves, peut-être parce que vos esclaves sont en cours d'exécution sur beaucoup moins de machines fiables que le maître, ou sont en cours d'exécution d'autres processus qui pourraient tuer la boîte en mangeant toutes ses CPU ou de la mémoire, et vous ne voulez pas prendre le risque d'une défaillance matérielle ou logicielle sur l'intermédiaire de l'esclave en prenant l'ensemble de votre esclave réseau. Que faites-vous?

Une solution de compromis pourrait consister à introduire une boîte supplémentaire dans votre esclave réseau d'agir en tant qu'intermédiaire, optimisé pour la fiabilité et de la performance plutôt que pour le stockage. Donnez-lui un petit, fiable disque SSD et exécutez rien sur elle à part un mysqld processus de réplication à partir de la télécommande maître, et de produire binlogs que les autres esclaves pouvez vous abonner. Et, bien sûr, mettre en place ce intermédiaires esclave d'utiliser le BLACKHOLE moteur, de sorte qu'il n'a pas besoin d'espace de stockage.

À la fois le présent et l'intermédiaire de filtrage de l'esclave est décrit en détail dans la documentation sont des cas limites; la plupart des utilisateurs MySQL ne sera jamais se trouver dans des situations où ils allaient bénéficier de l'aide de l'une de ces stratégies, sans parler des avantages suffisants pour justifier de faire le travail à leur place. Mais au moins théoriquement, la BLACKHOLE moteur peut être utilisé pour créer un intermédiaire nœud dans un réseau de réplication des esclaves, comme une bande-stratégie de conservation, sans avoir besoin de ce nœud pour enregistrer les données sur le disque.