Global : 作用于master/slave, Global级别的参数用于管理多组master/slave结构,可以统一化管理一些参数。
hostname
配置MySQL服务器的机器名或是IP地址,这个配置项是必须的,而且只能配置在[server_xxx]这个块下面。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
hostname | Yes | Local Only | - | hostname=mysql_server1, hostname=192.168.0.1, etc |
ip
MySQL服务器的ip地址。 默认从gethostname($hostname)中获得。 默认不用配置这个参数,MHA可以通过hostname自动获取,MHA通过IP地址连接MySQL服务器及SSH连接。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ip | No | Local Only | 通过gethostbyname($hostname)获得 | ip=192.168.1.3 |
port
MySQL运行的端口号。 默认是3306. MHA使用IP和端口号连接MySQL
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
port | No | Local/App/Glbal | 3306 | port=3306 |
ssh_host
(从MHA 0.53后开始支持) MHA要ssh上MySQL目标服务器使用hostname 或是ip地址。这个参数主要用于在使用多个VLAN的环境中。为了安全原因ssh默认不允许。默认这个参数和hostname相同。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ssh_host | No | Local Only | 和hostname相同 | ssh_host=mysql_server1, ssh_host=192.168.0.1, etc |
ssh_ip
(从MHA 0.53后开始支持) 和ssh_host作用相同。 默认是gethostname($ssh_host)获得。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ssh_ip | No | Local Only | gethostbyname($ssh_host) | ssh_ip=192.168.1.3 |
ssh_port
(从MHA 0.53后开始支持) SSH使用的端口号,默认是22.
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ssh_port | No | Local/App/Global | 22 | ssh_port=22 |
ssh_connection_timeout
(从MHA 0.54后支持)默认是5秒。在没添加这个参数之前ssh超时时间是写死的。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ssh_connection_timeout | No | Local/App/Global | 5 | ssh_connect_timeout=5 |
ssh_options
(从MHA 0.53后支持) 添加ssh命令行的支持参数,例如加上特别文件名的key的支持等。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ssh_options | No | Local/App/Global | “” 空的 | ssh_options=”-i /root/.ssh/id_dsa2″ |
candidate_master
你可能对于同一组slave中有着不同的规划,有的其望在Master故障时,提升为新的Master(如: Raid1+1的slave比Raid0的slave更适合做Master)
这个参数的作用是当设计candidate_master = 1时,这个服务器有较高的优先级提升为新的master(还要具备: 开启binlog, 复制没有延迟)。 所以当设置了candidate_master = 1的机器在master故障时必然成为新的master. 但这是很有用的设置优先级的一个参数。
如果设置了多台机器的caddidate_master = 1 , 优先策略依赖于块名字([server_xxx]). [server_1] 优衔权高于[server_2].
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
candidate_master | No | Local Only | 0 | candidate_mast=1 |
no_master
当设置了no_master = 1的服务器,这个服务器永远不会提升为新的master. 这个参数据对于永远不期望成为master的机器很有用。 如: 你可能需要在使用raid0的机器上设置no_master = 1 或是你希望在远程的idc里运行一个slave. 注意: 当没有可以成为新master的机器是MHA就直接退出来了同时停止监控和master故障切换。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
no_master | No | Local Only | 0 | no_master=1 |
ignore_fail
在默认情况下,MHA manager不会在slave存在故障的情况下(已经不能通过SSH/MySQL进行连接,或是SQL Thread已经停止出错,其它原因)的情况下进行Master的故障切换(当不存在slave时MHA manager也会退出)。 但有些情况下你期望在slave存在问题的情况下,也进行故障切换。 所以当设置了ignore_fail = 1时,MHA会在所有的机器有问题的时间也会进行故障切换。 默认是0.
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ignore_fail | No | Local Only | 0 | ignore_fail=1 |
#skip_init_ssh_check#
在MHA manager启动时跳过ssh检查。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
skip_init_ssh_check | No | Local Only | 0 | skip_init_ssh_check=1 |
skip_reset_slave
(从MHA 0.56开始支持) Master故障切换后新的master上执行RESET SLAVE(ALL).
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
skip_reset_slave | No | Local/App/Global | 0 | skip_reset_slave=1 |
user
用于管理MySQL的用户名。这个最后需要root用户,因为它需要执行:stop slave; change master to , reset slave. 默认: root
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
user | No | Local/App/Global | root | user=mysql_root |
password
MySQL的管理用户的密码。 默认是空的
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
password | No | Local/App/Global | 空的 | password=rootpass |
repl_user
MySQL用于复制的用户,也是用于生成CHANGE MASTER TO 每个slave使用的用户。 这个用户必须有REPLICATION SLAVE权限在新的Master上。默认情况下 repl_user会在将来成为master的机器上运行show slave status获取到。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
repl_user | No | Local/App/Global | 从show slave status | repl_user=repl |
repl_password
MySQL中repl_user用户的密码。 默认是当前复制用的密码。 当你使用online_master_switch时,当使用–orig_master_is_new_slave(原来的Master成为新Master的一个slave)时,如果没有repl_password 开启同步就会失败了。因为当前master上用于复制的用户名和密码都是空的(MHA在原来的Master上执行change master to 时没有带复制的密码,虽然其它slave上设置了复制的密码)
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
repl_password | No | Local/App/Global | 当前复制用的密码 | repl_password=replpas |
disable_log_bin
当设置了这个参数,在slave应用差异的relay log时不会产生二进制日志。 内部实现通过mysqlbinlog的disable-log-bin实现。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
disable_log_bin | No | Local/App/Global | 0 | disable_log_bin=1 |
master_pid_file
指定MySQL的pid文件。 这个参数在一台服务器上运行多个MySQL服务进程时非常有用。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
master_pid_file | No | Local/App/Global | - | master_pid_file=/var/lib/mysql/master1.pid |
ssh_user
MHA Mananger, MHA node系统上的用户。 这个帐号需要在远程机器上有执行权限(Manager->MySQL),在slave成员之间复制差异的relay-log(MySQL->MySQL)
这个用户必须有读取MySQL的binary/relay日志和relay_log.info的权限,还需要对远程MySQL上remote_workdir目录的写权限。
这个用户还必须可以直接ssh到远程机顺上, 推荐使用ssh pbulic key . 一般使用的ssh_user也是运行manager那个那个用户。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ssh_user | No | Local/App/Global | 当前使用的系统用户 | ssh_user=root |
remote_workdir
MHA node上工作目录的全路径名。如果不存在,MHA node会自动创建,如果不允许创建,MHA Node自动异常退出。 需要注意MHA manager 或是MHA node上需要检查空间是否可用,所以需要注意检查这个。 一般默认, remote_workdir是的”/var/tmp”
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
remote_workdir | No | Local/App/Global | /var/tmp | remote_workdir=/var/log/masterha/app1 |
master_binlog_dir
master上用于存储binary日志的全路径。这个参数用于当master上mysql死掉后,通过ssh连到mysql服务器上,找到需要binary日志事件。这个参数可以帮助用于无法找到master进程死掉后binary日志存储位置。
一般: master_binlog_dir是”/var/lib/mysql/, /var/log/mysql”. “/var/lib/mysql/”是大多数系统发行版本的存放位置,”/var/log/mysql”是ubuntu发行版本的存放位置。 你也可以设置多个存放位置用逗号隔开。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
master_binlog_dir | No | Local/App/Gobal | /var/lib/mysql | master_binlog_dir=/data/mysql1,/data/mysql2 |
log_level
设置MHA manager记录LOG的级别。 默认是info级别而且大多数情况也是比较适合。 同样可以设置为: debug/info/warning/error.
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
log_level | No | App/Global | info | log_level=debug |
manager_workdir
用于指定mha manager产生相关状态文件全路径。 如果没设置 默认是/var/tmp
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
manager_workdir | No | App | /var/tmp | manager_workdir=/var/log/masterha |
manager_log
指定mha manager的绝对路径的文件名日志文件。 如果没设置MHA Manager将打印到STDOUT/STDERR。 当手工执行故障切换(交互模式切换),MHA Manager会忽略manager_log设置直接将日志输出到STDOUT/STDERR.
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
manager_log | No | App | STDERR | manager_log=/var/log/masterha/app1.log |
check_repl_delay
在默认情况下,当一个slave同步延迟超过100M relay log(需要应用超过100M relay log), MHA在做故障切换时不会选择这个slave做为新的master,因为恢复需要经过很长时间.当设置了check_repl_delay = 0, MHA将忽略被选择的slave上的同步延迟。 这个选项在设置了candidate_master = 1特声明的期望这台机器成为master的情况下特别有用。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
check_repl_delay | No | App/Golbal | 1 | check_repl_delay=0 |
check_repl_filter
在默认下情况,当master和slave设置了不同了binary log/replication 过滤规则时,MHA直接报错不会进行监控和故障切换。 这些将会导致出现一些异想不到的错误”Table not exists”。如果你100%确认不同的过滤规则不会导致恢复中的错误,设置check_repl_filter=0。 需要注意: 当使用了check_repl_filter = 0时,MHA不会检查过滤规则在应用差异的relay日志,所以有可能会出现”Table not exists”的错误。当你设置了这个参数请小心处理。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
check_repl_filter | No | App/Global | 1 | check_repl_filter=0 |
latest_priority
在默认情况下,和Master最接近的slave(一个slave从Master上获得了最一个binlog事件)是最有优先权成为新的master。 如果你想控制一下切换的策略(如: 先选择host2,如果不行,选host3;host3不行,选host4…) 那么设置latest_priority = 0 就可以了。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
latest_priority | No | App/Global | 1 | latest_priority=0 |
multi_tier_slave
从MHA 0.52开始, 多层复制可以支持了。在默认情况下,不支持三层或是更多层的复制配置。 如果: host2从host1上复制,host3从host2上复制。 在默认配置的情况下不支持写host{1,2,3},因为这是一个三层的复制,MHA Manager会停止报错。 当设置了multi_tier_slave, MHA Manager就不会在三层复制报错停止。 但是会忽略第三层的机器。也就是如果host1挂了,host2将会成为新的master,host3还是从host2上进行复制。
这个参数在MHA Manager 0.52后的版开始支持。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
muli_tier_slave | No | App/Global | 0 | multi_tier_slave=1 |
ping_interval
这个参数设置MHA Manager多长时间去ping一下master(执行一些SQL语句). 当失去和master三次偿试,MHA Manager会认为MySQL Master死掉了。也就是说,最大的故障切换时间是4次ping_interval的时间,默认是3秒。
如果MHA Manager在和MySQL创建连接时都收到多连接错误或是认证错误,这个就不做重试就会认为master已经挂掉。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ping_interval | No | App/Global | 3 | ping_interval=5 |
ping_type
(从MHA 0.53后开始支持) 在默认情况下, MHA manager和MySQL创建一个连接执行”select 1″(ping_type=select)用于检查master是否健康。 但有一些情况: 每次检测都连接/然后断开会比较好一点,这样对于tcp方面的错误感知更快一点。设置ping_type=CONNECT 就行了。从MHA 0.56后pint_type=INSERT也被添加。
如:
参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
ping_type | No | App/Global | SELECT | ping_type=CONNECT |
secondary_check_script
一般来讲, 非常推荐使用更多网络上机器是不同路由策略上的机器来检查MySQL Master是否存活。 默认情况下,只有MHA Manager通过一个路由来检查Master是否存活。这个也是不推荐的。MHA可以通过外部secondary_check_script配置的脚本来做到从多个路由策略下进行检查。
secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2
secondary_check_script包含在MHA Manager发行包中。 MHA中内置的secondary_check_script在大多数情况下工作良好,但并不是任何地都可以使用这个脚本。
在上面的例子中, MHA Manager通过Manager->(A)->remote_host1->(B)->master_host 和Manager->(A)-remote_host2->(B)->master_host来检查MySQL master是否存活。如果在连接过程中通过A可以都成功,通过B是都失败,secondary_/check_/script返回0,而且认为master已经死掉,进行故障切换。如果通过A成功,但返回代码为: 2,则MHA manager有会认为是网络问题,则不会进行故障切换。如果A成功,B也成功,masterha_secondary_check 退出返回:3 则MHA Manager就为认为MySQL Master为存活状态, 则不会进行故障切换。
一般来讲, remote_host1和remote_host2是和MHA Manager及MySQL Server位于不同的网段中。
MHA会调用secondary_check_script声明的脚本并自动带上一些参数。 masterha_secondary_check在很多场景都是适用的,但是你也可以自已实现这个程序带有更多的功能。

Les étapes de mise à niveau de la base de données MySQL incluent: 1. Sauvegarder la base de données, 2. Arrêtez le service MySQL actuel, 3. Installez la nouvelle version de MySQL, 4. Démarrez la nouvelle version du service MySQL, 5. Récupérez la base de données. Des problèmes de compatibilité sont nécessaires pendant le processus de mise à niveau, et des outils avancés tels que Perconatoolkit peuvent être utilisés pour les tests et l'optimisation.

Les politiques de sauvegarde MySQL incluent une sauvegarde logique, une sauvegarde physique, une sauvegarde incrémentielle, une sauvegarde basée sur la réplication et une sauvegarde cloud. 1. Logical Backup utilise MySQLDump pour exporter la structure et les données de la base de données, ce qui convient aux petites bases de données et aux migrations de versions. 2. Les sauvegardes physiques sont rapides et complètes en copie les fichiers de données, mais nécessitent la cohérence de la base de données. 3. La sauvegarde incrémentielle utilise la journalisation binaire pour enregistrer les modifications, ce qui convient aux grandes bases de données. 4. La sauvegarde basée sur la réplication réduit l'impact sur le système de production en sauvegarde du serveur. 5. Les sauvegardes cloud telles que Amazonrds fournissent des solutions d'automatisation, mais les coûts et le contrôle doivent être pris en compte. Lors de la sélection d'une politique, de la taille de la base de données, de la tolérance aux temps d'arrêt, du temps de récupération et des objectifs de points de récupération doit être pris en compte.

MysqlclusteringenhancesdatabaserobustnessandscalabilityByDistritingDataacRossMultiplenodes.itUsEsthendBenginefordataReplication andfaultToleance, assurant la manière

L'optimisation de la conception du schéma de la base de données dans MySQL peut améliorer les performances par les étapes suivantes: 1. Optimisation d'index: Créer des index sur les colonnes de requête communes, équilibrant la surcharge de la requête et insertion des mises à jour. 2. Optimisation de la structure du tableau: Réduisez la redondance des données par normalisation ou anti-normalisation et améliorez l'efficacité d'accès. 3. Sélection du type de données: utilisez des types de données appropriés, tels que INT au lieu de Varchar, pour réduire l'espace de stockage. 4. Partionnement et sous-table: Pour les volumes de données importants, utilisez le partitionnement et la sous-table pour disperser les données pour améliorer l'efficacité de la requête et de la maintenance.

TOOPTIMIZEMYSQLPERFORMANCE, SuivreTheSestets: 1) Implémentation de PROPERIDEXINGTOSPEEDUPQUERIES, 2) Utiliser la manière dont la gamme ajustée en ligne

Les fonctions MySQL peuvent être utilisées pour le traitement et le calcul des données. 1. L'utilisation de base comprend le traitement des chaînes, le calcul de la date et les opérations mathématiques. 2. L'utilisation avancée consiste à combiner plusieurs fonctions pour implémenter des opérations complexes. 3. L'optimisation des performances nécessite d'éviter l'utilisation de fonctions dans la clause où et d'utiliser des tables groupby et temporaires.

Méthodes efficaces pour les données d'insertion par lots dans MySQL Incluent: 1. Utilisation d'inserto ... Syntaxe des valeurs, 2. Utilisation de la commande chargedatainfile, 3. Utilisation du traitement des transactions, 4. Ajuster la taille du lot, 5. Désactiver l'indexation, 6. Utilisation de l'insertion ou de l'insert ... onduplicatekeyupdate, ces méthodes peuvent améliorer considérablement l'efficacité du fonctionnement de la base de données.

Dans MySQL, ajoutez des champs en utilisant alterTableTable_namEaddColumnNew_Columnvarchar (255) AfterExist_Column, supprimez les champs en utilisant alterTableTable_NamedRopColumnColumn_to_drop. Lorsque vous ajoutez des champs, vous devez spécifier un emplacement pour optimiser les performances de la requête et la structure des données; Avant de supprimer les champs, vous devez confirmer que l'opération est irréversible; La modification de la structure de la table à l'aide du DDL en ligne, des données de sauvegarde, de l'environnement de test et des périodes de faible charge est l'optimisation des performances et les meilleures pratiques.


Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
Échangez les visages dans n'importe quelle vidéo sans effort grâce à notre outil d'échange de visage AI entièrement gratuit !

Article chaud

Outils chauds

Télécharger la version Mac de l'éditeur Atom
L'éditeur open source le plus populaire

Version crackée d'EditPlus en chinois
Petite taille, coloration syntaxique, ne prend pas en charge la fonction d'invite de code

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Navigateur d'examen sécurisé
Safe Exam Browser est un environnement de navigation sécurisé permettant de passer des examens en ligne en toute sécurité. Ce logiciel transforme n'importe quel ordinateur en poste de travail sécurisé. Il contrôle l'accès à n'importe quel utilitaire et empêche les étudiants d'utiliser des ressources non autorisées.

Adaptateur de serveur SAP NetWeaver pour Eclipse
Intégrez Eclipse au serveur d'applications SAP NetWeaver.
