Pensées Libres dans un Monde Binaire
Articles traitant d’informatique, du sujet général au plus particulier.
Petit aide-mémoire en cas d’indisponibilité du port série dans l’IDE Arduino et constaté sous Arch Linux.
Le problème provient d’un manque de permission sur le répertoire /run/lock pour l’IDE.
# chown root:wheel /run/lock # chmod 775 /run/lock
Autre possibilité, démarrer l’IDE en root.
uname
Nom du système
uname -a
Divers informations concernant le système
arch
Type de microprocesseur
lsb_release -a
Informations détaillées sur la distribution installée (Nom, version, …)
find . -name '*.orig' -print
Permet de trouver tous les fichiers portant l’extension .orig dans le répertoire courant et dans tous les sous-répertoires et les affiche sur la sortie standard.
Pour supprimer directement les fichiers trouvés, on pourra utiliser:
find . -name '*.orig' -exec rm -f {} ';'
La suite de mon étude concernait le processus de sharding. Comme pour la réplication, les informations proviennent cette fois du guide sur le sharding.
Le sharding divise la donnée et la distribue sur plusieurs machines, aussi appelé shard et résout ainsi le problème de scaling horizontal. Un cluster est constitué de shard, serveur de configuration et mongos. Le sharding réduit la quantité de donnée que chaque serveur doit stocker, ainsi que le nombre d’opérations à effectuer.
Sharded cluster = shards + query routers (mongos) + config servers
Stock la donnée.
En production, pour des questions de haute disponibilité et de consistence des données, chaque shard est un replica set et le cluster est constitué de deux shards ou plus.
Sert d’interface avec l’application cliente et dirige les opérations vers le shard approprié. Un cluster peut contenir plusieurs routeurs pour distribuer la charge.
En production, un mongos ou plus.
Les curseurs et d’autres ressources étant spécifique à une instance de mongos, chaque client doit interagir avec seulement un mongos.
Stock les métadatas du cluster.
Contient un mapping entre les données du cluster et les shards (Quelle donnée se trouve sur quel shard). En production, un cluster possède exactement 3 config servers.
Si un ou deux serveurs de configuration deviennent indisponible, les métadatas du cluster passe en lecture seule jusqu’à ce que les trois serveurs soient à nouveau disponible. Il est toujours possible de lire et d’écrire sur les shards mais aucune migration et aucun découpage n’aura lieu sur les chunks.
Les sauvegardes de ces serveurs sont critiques.
Si le nom ou l’adresse qu’un cluster utilise pour se connecter à un serveur de configuration change, il est nécessaire de redémarrer tous les mongod et les mongos! D’où l’utilité des CNAMEs pour identifier les serveurs de configuration.
Chaque serveur doit être sur une machine séparée.
Le partitionnement s’effectue en utilisant une clé de sharding (sharding key).
Soit un champ indexé ou champ indexé composé existant dans tous les documents de la collection. MongoDB divise la shard key en morceaux (chunks) et les distribue de manière égale entre les shards. La division de la clé s’effectue soit avec un range based partitioning ou un hash based partitioning.
Pour sélectionner une shard key, déterminer les champs communément inclut dans les requêtes pour une application précise et déterminer quelles opérations demandent le plus de performance.
L’index sur la shard key ne peut pas être un multikey index.
Séparation des données en plusieurs intervalles. Deux documents avec une clé de sharding proche ont de grandes chances d’être dans le même chunk. Néanmoins, il peut en résulter une distribution inégale des données sur les shards. Plus efficace en cas de requêtes sur des intervalles. Le router peut déterminé plus facilement vers quels shards diriger la requête.
MongoDB calcule un hash de la valeur du champ et utilise ces hashs pour créer les chunks. Deux documents avec une clé de sharding proche ont très peu de chance d’être dans le même chunk. Cela permet de s’assurer d’une distribution plus aléatoire des données au sein du cluster et assure une distribution régulière des données sur les shards. Une requête sur un intervalle à de grande chance de s’adresser à tous les shards.
Mongo dispose de mécanismes pour éviter qu’un shard devienne trop grand: splitting et le balancer.
Lorsqu’un chunk devient trop grand, mongo le divise en deux.
Ceci n’affecte pas les données ou les shards.
Permet de migrer des chunks. Lorsque la distribution des données devient irrégulière, le balancer va migrer des chunks du shard avec le plus grande nombre de chunks à celui qui en possède le moins. Les données sont retirés du shard d’origine après une migration totale et réussie des données.
Cette semaine, j’ai eu l’occasion de commencer à étudier le fonctionnement de la réplication et du sharding avec MongoDB. Voici diverses informations provenant du guide sur la réplication.
La réplication consiste à écrire la donnée sur plusieurs serveurs et répond ainsi au problématique de haute disponibilité et de redondance des données. Elle permet, dans certains cas, d’augmenter les capacités en lecture. Un replica set peut avoir jusqu’à 12 membres dont 7 voteront à la fois. Pour disposer de plus de 12 instances, il est nécessaire de passer à la réplication maître-esclave.
L’architecture standard pour un replica set en production se compose de trois membres. Si l’application se connecte à plusieurs replica set, chacun doit avoir un nom différent. Les membres s’envoient des ping toutes les 2 secondes.
Replica Set: Groupe de mongod disposant des mêmes (~~) données.
On distingue deux types principaux de mongod dans un replica set: les primaires et les secondaires.
Il est unique et reçoit toutes les opérations d’écriture. Tous les changements sont conservés dans son oplog. Une élection d’un nouveau mongod primaire à lieux, si l’actuel ne communique avec aucun membre du replica set pendant 10s.
Récupère le oplog et applique les opérations sur son jeu de données. En cas d’indisponibilité du primaire, un mongod secondaire sera élu à sa place.
Mongod secondaire qui ne peut pas devenir primaire et ne peut déclencher d’élections. Permet de s’assurer que seul les membres qui en ont les capacités deviendront primaire (distribution géographique, hardware). Il est conseillé de s’assurer que le datacenter principal contient les votants et les membres éligibles.
Invisible pour les applications clientes. Sont toujours des membres à priorité 0, ne peuvent devenir primaire mais peuvent voter. En cluster, mongos n’interagit pas avec les membres cachés.
Reflète un état retardé de l’état du groupe.
Requis:
* Doit être un membre à priorité 0
* Devrait être un membre caché
Le délai doit être plus petit que la capacité de oplog. Cette fonctionnalité est utile pour pouvoir appliquer un rollback (retour en arrière) en cas d’erreur humaine.
Sa fonction est de voter en cas d’élection d’un mongod primaire et permet d’obtenir une majorité en cas d’un nombre pair de membres.
Important: Ne pas ajouter d’arbitre sur les machines hébergeant déjà un primaire ou un secondaire.
Déployer un nombre impair de membres pour s’assurer qu’un primaire pourra toujours être élu. Ajouter un arbitre si besoin.
Tolérance aux fautes: Correspond au nombre de membres auquel on soustrait la majorité requise pour élire un nouveau mongod primaire.
Au moins un membre à priorité 0 dans un autre datacenter. Garder une majorité de membre au même endroit.
Le sharding est souvent une meilleur stratégie pour augmenter les capacités en lecture et en écriture.
* primary
* primaryPreferred
* secondary
* secondaryPreferred
* nearest
Seul primary permet d’être sûr d’avoir des données totalement à jour.
Utiliser readPref() dans mongo shell pour accéder aux préférences.