continuation doc Orchestrator
This commit is contained in:
parent
78b0955c96
commit
bc0280307d
|
|
@ -74,6 +74,7 @@ CREATE USER 'orchestrator_client'@'orchestrator_host' IDENTIFIED BY 'password';
|
|||
GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator_client'@'orchestrator_host';
|
||||
GRANT SELECT ON mysql.slave_master_info TO 'orchestrator_client'@'orchestrator_host';
|
||||
GRANT SELECT ON ndbinfo.processes TO 'orchestrator_client'@'orchestrator_host'; -- seulement pour un cluster NDB
|
||||
GRANT SELECT ON performance_schema.replication_group_members TO 'orchestrator_client'@'orchestrator_host'; -- Only for Group Replication / InnoDB cluster
|
||||
~~~
|
||||
|
||||
> `REPLICATION SLAVE` est requis pour `SHOW SLAVE HOSTS`, and pour scanner les binlogs si on utilise les `Pseudo GTID`. `RELOAD` est requis pour pourvoir faire un `RESET SLAVE`. `PROCESS` est requis pour surveiller les process des réplicas avec `SHOW PROCESSLIST`.
|
||||
|
|
@ -90,3 +91,105 @@ Ensuite on peux démarrer Orchestrator comme ceci :
|
|||
~~~
|
||||
# systemctl start orchestrator.service
|
||||
~~~
|
||||
|
||||
### Configuration : Découverte des serveurs SQL par résolution de nom
|
||||
|
||||
Si on veux que orchestrator fasse la découverte des serveurs SQL avec la résolution de nom on peut mettre cette configuration dans `/etc/orchestrator.conf.json` :
|
||||
|
||||
~~~
|
||||
{
|
||||
"HostnameResolveMethod": "default",
|
||||
"MySQLHostnameResolveMethod": "@@hostname",
|
||||
}
|
||||
~~~
|
||||
|
||||
### Configuration : Classement des serveurs
|
||||
|
||||
Orchestrator peut classer les serveurs en fontion du nom du cluster, du datacenter, etc...
|
||||
|
||||
Voici la configuration qu'on mets par défaut :
|
||||
|
||||
~~~
|
||||
{
|
||||
"ReplicationLagQuery": "",
|
||||
"DetectClusterAliasQuery": "select ifnull(max(cluster_name), '') as cluster_alias from meta.cluster where anchor=1",
|
||||
"DetectClusterDomainQuery": "select ifnull(max(cluster_domain), '') as cluster_domain from meta.cluster where anchor=1",
|
||||
"DetectInstanceAliasQuery": "",
|
||||
"DetectPromotionRuleQuery": "",
|
||||
"DataCenterPattern": "[.]([^.]+)[.][^.]+[.]mydomain[.]com",
|
||||
"PhysicalEnvironmentPattern": "[.]([^.]+[.][^.]+)[.]mydomain[.]com",
|
||||
}
|
||||
~~~
|
||||
|
||||
#### Replication lag
|
||||
|
||||
Par défaut Orchestrator utlise `SHOW SLAVE STATUS` et à une tolérrance de 1 seconde de lag.
|
||||
Il ne tient pas en compte de décalages en cascade en cas de réplication chaînéé.
|
||||
Si on veux modifié ce comportement, on peut utilisé des outils personalisés tel que `pt-heartbeat`, ça fourni une décalage "absolu" par rapport au primaire, ainsi qu'un lag inférieur à la seconde.
|
||||
|
||||
#### Cluster alias
|
||||
|
||||
Dans votre topologie vos instances portent différents nom tel que "main", "inst01" etc... Cependant les cluster MySQL eux-même ne connaissent pas ces noms.
|
||||
|
||||
`DetectClusterAliasQuery` est une requpête par laquelle vous permettrez a Orchestrator de connaître le nom de votre cluster.
|
||||
|
||||
Le nom est important, on l'utilise pour indiquer à Orchestrator des éléments tels que "veuillez récupérer automatiquement ce cluster" ou "quelles sont toutes les instances participantes dans ce cluster".
|
||||
|
||||
Pour rendre ces données accessibles par une requête, on créer une table dans un méta schéma, comme ceci, sur les serveurs SQL :
|
||||
|
||||
~~~sql
|
||||
CREATE TABLE IF NOT EXISTS cluster (
|
||||
anchor TINYINT NOT NULL,
|
||||
cluster_name VARCHAR(128) CHARSET ascii NOT NULL DEFAULT '',
|
||||
cluster_domain VARCHAR(128) CHARSET ascii NOT NULL DEFAULT '',
|
||||
PRIMARY KEY (anchor)
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
|
||||
~~~
|
||||
|
||||
et on peuple la table comme ceci (on peux le faire également par Ansible ou un cron) :
|
||||
|
||||
~~~
|
||||
mysql meta -e "INSERT INTO cluster (anchor, cluster_name, cluster_domain) VALUES (1, 'TestEvoCluster', 'EvoCluster') ON DUPLICATE KEY UPDATE cluster_name=VALUES(cluster_name), cluster_domain=VALUES(cluster_domain)";
|
||||
~~~
|
||||
|
||||
#### Data center
|
||||
|
||||
Orchestrator classe les topologies de cluster SQL dans des `Data Center`, cela les colorera joliment dans l'interface web, mais il prendra en compte la variable `Data Center` lors de l'exécution des basculements.
|
||||
|
||||
On configure la reconnaissance du `Data Center` selon l'une des deux méthodes :
|
||||
|
||||
* `DataCenterPattern` : Une expression régilière à utliser sur le FQDN : `"[.]([^.]+)[.][^.]+[.]mydomain[.]com"`
|
||||
* `DetectDataCenterQuery` : une requête qui renvoie le nom du `Data Center`
|
||||
|
||||
### MySQL / MariaDB Configuration
|
||||
|
||||
Vos topologies MySQL doivent remplir certaines conditions pour prendre en charge les bascules.
|
||||
Ces exigences dépendent en grande partie des types de topologies / configuration que vous utilisez.
|
||||
|
||||
* Oracle/Percona avec GTID : les serveurs pouvant être promus doivent avoir `log_bin` et `log_slave_updates` activés. Les secondaires doivent utliser `AUTO_POSITION=1` (via CHANGE MASTER TO MASTER_AUTO_POSITION=1)
|
||||
* MariaDB GTID : les serveurs pouvant être promus doivent avoir `log_bin` et `log_slave_updates` activés.
|
||||
|
||||
### Configuration : Détection de panne
|
||||
|
||||
Orchestrator peut détectera toujours les pannes de votre topologie. Dans la configurayion on peut définir la fréquence d'intérogation et des moyens spécifiques pour que Orchestrator vous avertisse d'une telle détection.
|
||||
|
||||
Considérez également que vos topologies MySQL elles-mêmes doivent suivre certaines règles, voir `MySQL / MariaDB Configuration`
|
||||
|
||||
Voici la configuration de base pour la détection de panne :
|
||||
|
||||
~~~
|
||||
{
|
||||
"RecoveryPeriodBlockSeconds": 3600,
|
||||
"RecoveryIgnoreHostnameFilters": [],
|
||||
"RecoverMasterClusterFilters": [
|
||||
"*"
|
||||
],
|
||||
"RecoverIntermediateMasterClusterFilters": [
|
||||
"_intermediate_master_pattern_"
|
||||
],
|
||||
}
|
||||
~~~
|
||||
|
||||
* Orchestrator récupérera automatiquement les pannes principales intermédiaire pour tous les clusters.
|
||||
* Orchestrator récupérera automatiquement les défaillances pour tous les clusters, les primaire des autres cluster ne récupéreront pas automatiquement. Un humain pourra initier des récupérations.
|
||||
* Une fois qu'un cluster a connu une récupération, Orchestrator bloque les récupérations automatiques pendant 3 600 secondes (1 heure). C'est un mécanisme anti-flap.
|
||||
|
|
|
|||
Loading…
Reference in a new issue