MySQL InnoDB sur un périphérique brut dans une topologie active/passive

Question

Nous avons une topologie Actif/Passif où il y a deux complexes x86 avec un stockage brut partagé, où un seul des nœuds à un moment donné a accès au stockage partagé (AKA le nœud actif).En cas de basculement dans le nœud actif, le nœud passif initie une prise de relais et devient le nœud actif avec un accès au stockage partagé.Chaque nœud possède son propre stockage de périphérique de démarrage avec un système de fichiers.Cependant, le stockage partagé ne peut pas contenir de système de fichiers.

Nous souhaitons installer MySQL sur les deux nœuds, où ses données résident dans le stockage partagé et où seul le nœud actif exécute le serveur.

MySQL avec InnoDB est capable de fonctionner sur un appareil brut, et il y a aussi un guide sur la façon d'exécuter MySQL sur un cluster similaire à notre topologie.Cependant, dans le deuxième exemple, ils disposent d'un système de fichiers monté sur le stockage partagé.Le problème du système de fichiers soulève une préoccupation majeure :

ib_logfile* nécessite toujours un système de fichiers.Ainsi, la fonctionnalité brute de MySQL n'est pas exactement entièrement brute.Veuillez me corriger si je me trompe.Existe-t-il une solution de contournement pour stocker ces fichiers dans le stockage brut ?Nous pouvons sauvegarder les journaux de rétablissement (ib_logfile0, ib_logfile1) dans le périphérique de démarrage du nœud et supprimez toujours ces fichiers avant le démarrage du serveur (nous n'aurons donc pas d'anciens fichiers journaux en cas de basculements multiples).Cependant, cela pourrait conduire à ce que la transaction non validée soit partiellement validée en cas d'échec au milieu d'une transaction, contredisant ainsi l'idée même de transaction.

Existe-t-il d'autres fichiers/fonctionnalités susceptibles d'affecter le comportement de MySQL dans cette topologie ?

Answer 1

Il convient de noter que le journal d'écriture anticipée (WAL) d'InnoDB, le ib_logfile*, n'est pas la seule chose qui nécessitera un système de fichiers.Tu as:

1. Tables système du schéma MySQL qui utilisent probablement le moteur de stockage MyISAM (.frm, .MYD, .MYI par table) (la plupart utilisent désormais InnoDB dans la version 5.7)
2. Fichiers .frm pour chaque table InnoDB, même lors de l'utilisation de l'espace de table système partagé (métadonnées de table requises)
3. Fichiers journaux MySQL (journal des erreurs, journal général, journal binaire)
4. Artefacts SSL
5. auto.cnf (où l'UUID de l'instance MySQL est généré et automatiquement stocké)
6. db.opt pour chaque schéma (dans /<datadir>/<schema>/)
7. Fichier .par si vous créez une table partitionnée (disparu en 5.7)
8. Fichiers .trn et .trg si vous créez des déclencheurs
9. Espace de table tmp InnoDB (5.6+)
10. Carte des pages du pool de tampons persistants (ib_buffer_pool, 5.6+)

Tout ce qui précède se situe généralement dans le cadre répertoire de données, donc tant que vous avez datadir=/some/valid/fs/path -- qui est également répliqué (par ex.DRBD) ou partagé (par ex.NFS, GFS, OCFS) entre les deux nœuds – alors tout ira bien.

Il convient de noter que les fichiers .frm, .par, .trn, .trg et .opt disparaîtront avec le nouveau dictionnaire de données.

Restez à l’écoute pour de grandes annonces dans les mois à venir !:)

Je ne comprends pas pourquoi vous utilisez l'appareil RAW ?Je suis sûr que vous avez vos raisons.:)

Bonne chance!

Answer 2

La technique de stockage brut n'est valable que pour ibdata1 avec innodb_file_per_table désactivé.

J'ai mentionné cette configuration à plusieurs reprises

• Jul 25, 2012 : Conception de base de données - Création de plusieurs bases de données pour éviter le casse-tête lié à la limite de taille des tables
• Feb 26, 2013 : Maintenance dans MYSQL lorsque innodb_file_per_table est désactivé

Remarque sur l'architecture InnoDB (Photo du CTO de Percona, Vadim Tkachenko)

Avec innodb_file_per_table désactivés, les données et les index de toutes les tables InnoDB atterriraient dans le stockage brut avec le tampon d'écriture double, le tampon d'insertion, le dictionnaire de données, les segments d'annulation et l'espace d'annulation.

En ce qui concerne les journaux redo, vous devriez envisager d'avoir un petit périphérique de bloc DRBD juste pour contenir /var/lib/mysql, avec ib_logfile0 et ib_logfile1 dans ce dossier.Ainsi, le basculement se déroulerait comme suit

• Rompre DRBD entre les deux serveurs
• Définissez l'état DRBD du nouveau serveur sur Primary/Unknown
• Montez DRBD sur /var/lib/mysql
• Monter le périphérique brut avec les informations d'ibdata1
• service mysql start
• Synchroniser les appareils DRBD
• Installation Stimulateur cardiaque/ucarpe services pour préparer le prochain basculement

J'ai préféré DRBD/ucarp pour les configurations de basculement. Voir mes anciens messages à leur sujet

MISE À JOUR 2015-10-14 11h30 HAE

Comme je l'ai déjà mentionné, les journaux redo doivent être dans le périphérique de bloc DRBD monté sur /var/lib/mysql.En ce qui concerne d'autres dossiers essentiels tels que

• journaux binaires
• journaux de relais
• journal des erreurs
• journal lent
• journal général

tous ces fichiers doivent être dans /var/lib/mysql aussi.De cette façon, les basculements transporteront tout ce qui concerne MySQL (moins les données brutes qui se trouvent sur leur propre disque).

AVERTISSEMENT :Cette configuration n'est pas destinée aux tables MyISAM.Si un basculement matériel se produit, toutes les tables MyISAM ouvertes avant le crash/basculement seront marquées comme corrompues et nécessiteront une exécution. REPAIR TABLE sur tous affectent les tables MyISAM.

Si toutes vos tables sont InnoDB, ignorez cet avertissement.Si vous convertissez vos tables MyISAM restantes en InnoDB, vous pouvez ignorer cet avertissement.(NE CONVERTISSEZ AUCUNE TABLE MyISAM DANS LE mysql SCHÉMA DANS InnoDB).