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 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 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 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`.
|
> `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
|
# 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