mysql group replication自动主从切换吗
mysql> show processlist\G*************************** 1. row ***************************Id: 3User: system userHost:db: NULLCommand: ConnectTime: 2601State: Slave has read all relay log; waiting for the slave I/O thread to update itInfo: NULL*************************** 2. row ***************************Id: 4User: rootHost: localhostdb: NULLCommand: Query为获得最佳兼容性和性能，组的所有成员为了 Group Replication，应运行相同版本的 MySQL Server。但是，在某些情况下，可能需要组内有不同版本的服务器运行共存。例如，在滚动升级期间。当组中存在不同的版本时，某些成员可能与其他成员不兼容，因为它们支持其他人没有或缺乏其他人所具有的功能。因此，组复制需实现兼容性策略以防止运行到不兼容的版本组合方案。在 MySQL 8.0.17 中，组复制为组中的成员版本实现的兼容性策略考虑了成员的 MySQL Server 版本的补丁版本。以前，只考虑过主要版本。使用维护版本(8.0.17)意味着组复制可以在组重新配置和升级过程中更好地维护混合版本组的复制安全性。1. 主成员选项A.主成员选举算法具有 8.0.17 或更高版本成员的组具有至少一个 8.0.16 或更低成员版本的组B.用户触发主切换具有 8.0.17 或更高版本成员的组具有至少一个 8.0.16 或更低成员版本的组2. 写版本兼容性3. 最低版本兼容性4. 捐赠者版本兼容性5. 升级6. 结论主成员选项选择新的主节点时的参数之一是用于复制安全性的成员版本。从 8.0.17 开始，在选择新主时也考虑补丁级别。因此，基于组配置的下一个主要内容存在细微差别。在主成员的故障转移期间，基于以下算法选择新的主成员：具有 8.0.17 或更高版本成员的组该组中的所有成员都具有 8.0.17 或更高版本。1. 该组的最低成员版本，包括补丁级别2. 根据步骤-1，该组中版本最低成员的成员权重较高3. 服务器 uuid 的词法排序在相同成员权重的组内是最低的例子例1：主成员退出后的小组：8.0.19 / 8.0.20 / 8.0.208.0.19 将因其最低版本，开始被选为主服务器。例2：主成员退出后的小组：8.0.19 权重：90 / 8.0.19 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95“版本 8.0.19 权重：90”的服务器将被选为主要服务器，因为它是组内的最低版本且有较高的权重。例3：主成员退出后的小组：8.0.19 权重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c8.0.19 权重：90 uuid：5a67adc9-6ad1-11e7-9b1f-f48c5048ab0c8.0.19 权重：50 uuid：5a6e5078-6ad1-11e7-9bce-f48c5048ab0c“8.0.19 权重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c”的服务器将被选为主，因为其具有较高成员权重和最低服务器 uuid。具有至少一个 8.0.16 或更低成员版本的组该组中至少有 1 名成员，版本低于 8.0.17。1. 考虑主要版本的该组的最低成员版本2. 根据步骤-1，该组中最低成员的成员权重较高3. 服务器 uuid 的词法排序在相同成员权重的组内是最低的例1：主成员退出后的小组：5.7.22 / 8.0.20 / 8.0.205.7.22 版本的服务器将从其最低版本的组中被选为主服务器。如果主成员被修改为使用UDF，group_replication_set_as_primary(server_uuid)或 group_replication_switch_to_single_primary_mode([server_uuid])，则还会采取一些预防措施以确保所有成员兼容并可以执行所需的更改。算法如下：具有 8.0.17 或更高版本成员的组该组中的所有成员都具有 8.0.17 或更高版本。1. 如果提供了 server_uuid，则该服务器将成为主成员，如果其版本在组中最低(考虑补丁级别)，否则将引发错误。2. 如果未提供 server_uuid，则考虑组成员版本直到补丁级别进行选举。例子例1：多主模式到单主模式切换时的组成员：8.0.19 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95“版本 8.0.19 权重：50”的服务器将被选为主服务器，因为它的补丁是该组的最低版本。具有至少一个 8.0.16 或更低成员版本的组该组中至少有 1 名成员，版本低于8.0.17。1. 如果组中的任何成员的版本为 5.7 或版本低于 8.0.13，则该函数不会对主成员进行任何更改。2. 如果主要版本 8 提供的 server_uuid，那么该服务器将成为主成员，否则将抛出错误。3. 如果未提供 server_uuid，则考虑到组成员版本的唯一主版本，将进行选举。注意：对于 UDF group_replication_set_as_primary，server_uuid 是必需的。如果未提供 server_uuid，UDF 将失败。例1：多主模式到单主模式切换时的组成员：8.0.14 权重：90 / 8.0.20 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95“版本 8.0.20 权重：95”的服务器将被选为主服务器，因为该组的最低主要版本(由于组中存在 8.0.14 而忽略了维护版本)。从 8.0.17 开始，如果新成员版本高于组的最低成员版本(考虑补丁级别)，则新成员将处于只读模式。如果该组通过执行 UDF group_replication_switch_to_multi_primary_mode 进入多主模式，则该组的最低成员版本将是可写的，而其他成员将处于只读状态。版本为 8.0.16 或更低版本的成员，如果组中的任何成员具有 5.7 版本，则以只读模式加入组。版本 5.7 的成员始终可写，因为 5.7 仅考虑主要版本。在 MySQL 5.7 和 8.0 中，直到补丁级别 16，当低版本成员离开组时，用户必须手动重新配置只读模式。注意：这仅适用于多主模式。例1：多主模式的组成员：8.0.19 / 8.0.20版本 8.0.19 的服务器将是可写的，而 8.0.20 将是只读的。例2：组成员在单主模式到多主模式切换期间：8.0.19(主)/ 8.0.19(副)/ 8.0.20(副)/ 8.0.21(副)版本 8.0.19 的服务器将是可写的，而 8.0.20 和 8.0.21 将是只读的多主模式开关。例3：多主模式的组成员：5.7.21 / 8.0.15版本为 5.7.21 的服务器是可写的，而 8.0.15 将是只读的。例4：组成员在单主模式到多主模式切换期间：8.0.14(副)/ 8.0.15(副)/ 8.0.20(副)/ 8.0.21(主)版本 8.0.14 和 8.0.15 的服务器是可写的(旧版本)，而 8.0.20 和 8.0.21 将是只读的。Server 8.0.21 将启用只读模式。从 8.0.17 开始，如果新成员版本低于该组的最低成员版本(考虑补丁级别)，则新成员将不加入该组。版本 5.7 的成员无法加入仅包含 8.0+ 成员的组。8.0.16 或更低版本的成员可以加入任何组，因为它只考虑主要版本。例1：小组成员：8.0.19 / 8.0.20 / 8.0.20版本为 8.0.17 或 8.0.18 的服务器将无法加入该组。例2：小组成员：8.0.15 / 8.0.16版本为 5.7.27 的服务器将无法加入该组。捐赠者版本兼容性从 8.0.17 开始，在形成可能的捐赠者组列表的同时，具有与新成员相同或更低版本的 ONLINE 成员被视为有效捐赠者。但是，如果设置了 allow_local_lower_version_join，则该组的所有 ONLINE 成员都可以充当有效的捐赠者，因为没有相同或更低版本的成员。5.7 级别或 MySQL 8.0 至 8.0.16 的组复制版本将所有 ONLINE 成员视为恢复的主动捐助者。5.7.22 / 8.0.20 / 8.0.21新成员 8.0.20 可以使用 5.7.22 或 8.0.20 作为捐赠者。5.7.22 / 8.0.20 / 8.0.21新成员 5.7.22 可以使用 5.7.22, 8.0.20 或 8.0.20 作为捐赠者。对于单主升级，用户可以先更新每个副成员，然后再更新主成员。以后的用户可以使用 UDF group_replication_set_as_primary 使所需的成员成为主成员。或者用户可以将更高的成员权重分配给所需的成员和升级组，首先升级所需的主成员。对于多主升级，可以按任何顺序升级成员。在完成组升级的过程中，由于版本较高，升级后的成员将处于只读模式。一旦该组的所有成员升级到相同的补丁级别，所有成员都将变为可写。关于不期望升级的一些注意事项：如果其版本低于该组的最低成员版本，则成员将不会加入该组(考虑补丁级别)∘ 如果升级后，版本不会是相同的补丁级别，则应首先启动新的最低成员版本。如果组中的所有成员的版本都大于 8.0.16，则只有当成员是组中的最低版本(包括修补程序级别)时，才允许该成员成为主要成员。∘ 如果主要升级后必须保持相同的升级，则主要升级(包括补丁级别)可能不会通过此 WL。应将组的辅助成员升级到高于或等于主要成员版本的版本。例1(单主升级)M1：8.0.20(旧主)/ M2：8.0.20(新主)/ M3：8.0.201. DBA 希望将所有组成员升级到 8.0.212. 在 M2 上设置更高的成员权重并升级 M23. 立即升级 M3 和 M14. M1 和 M3 升级后， M2 将成为主要例2(单主升级)M1：8.0.20(主)/ M2：8.0.20 / M3：8.0.201. DBA 希望将所有组成员升级到 8.0.212. 将 M2 和 M3 升级到 8.0.21 或更高版本3. 在 M2 和 M3 升级后，M1 可以升级到 8.0.214. 使用 UDF group_replication_set_as_primary M1 可以成为主例3：(多主升级)M1：8.0.20 / M2：8.0.201. DBA 希望将所有组成员升级到 8.0.212. 升级 M13. M1 升级后，M1 将是只读的，直到 M2 升级到 8.0.214. 一旦 M2 升级到 8.0.21，M1 将变为可写MySQL 8.0.17 是公开可用的，随之而来的是对组复制的改进。现在，组复制可以增加安全性，并确保成员生成的事务与组中的每个成员兼容。
mysql 双主模式和主从模式的区别
最大区别是 主从是对主操作数据，从会实时同步数据。反之对从操作，主不会同步数据，还有可能造成数据紊乱，导致主从失效。 主主则是无论对那一台操作，另一个都会同步数据。一般用作高容灾方案主从复制基本用过，双主模式不太清楚。
MySQL数据库的主从配置有哪些呢？
1',
##主服务器的IP
>MASTER_PORT=3306,
##3306不能加引号，此行可有可无
>MASTER_USER='repl',
>MASTER_PASSWORD='redaht';
>START SLAVE;
到此，主从mysql服务器配置完成！
在主服务器上对数据库进行修改，如：
# mysql
>CREAT DATABASE mydb;
在从服务器端查看：
# mysql
>SHOW DATABASES;
这里也将出现一个名为mydb的一模一样的数据库！
编辑特别推荐:
事务队列等待深入分析：索引争用
ORACLE建表时提示缺少右括号
常用的SQL注射语句解析。
你需要做的就一步：打开MS-DOS窗口，切换到C:\mysql?
点开始
运行，输入：CMD。就可以打开MS-DOS窗口了，输入：cd C:\mysql\bin，就切换到“C:\mysql\bin”目录了，XP里就是这样切换的。以上是详细过程。
求讲一下mysql的主从同步，和互为主从
主从同步首先设置mysql日志模式为binlog模式，在这种模式下对数据库的所有操作都会在bin文件中生产对应的操作sql语句，这时候备机就可以通过读取bin中的sql语句到本地来执行，如此就能实现备机和主机的数据库同步。
互为主从也是一样的道理。不是，mysql主从同步会同步主库的更改操作。包括数据的增删改查，也有表结构的变更，例如字段类型更改，字段添加删除等。
如果设置主从同步的时候设置的全库，那么增加一个表也会同步。
mysql主从的工作模式有哪些
主从就是读写分离，主数据库负责写服务器，实时同步到从数据库(硬件和网络不同情况会有不同时间的延迟，阿里云主从数据库延迟几十毫秒)，从数据库负责提供读取服务器，创建只读账号不能创建表和写入数据。双主集群没听过，你说的是不是Mysql的MMM架构，当一个主从挂掉了自动切换到另外一个主从服务器，当这个恢复后自动把增加的数据拷贝回来并提供服务1.从库太多导致复制延迟
优化：建议从库数量3-5个为宜
2.从库硬件比主库硬件差
优化：提升硬件性能
3.慢sql语句过多
优化：sql语句执行时间太长，需要优化sql语句
4.主从复制的设计问题
优化：主从复制单线程，可以通过多线程io方案解决；另外mysql5.6.3支持多线程io复制。
5.主从库之间的网络延迟
优化：尽量链路短，提升端口带宽
6.主库读写压力大
优化：前端加buffer和缓存。主从延迟不同步：
不管有多延迟，只要不影响业务就没事
7、业务设计缺陷导致延迟影响业务
优化：从库没有数据改读主库
