一、MySQL高可用之组复制（MGR）

1.1 组复制核心特性与优势

        MySQL Group Replication（MGR）是基于分布式一致性协议（Paxos）实现的高可用集群方案，核心特性包括：

        自动故障检测与恢复：集群自动检测故障节点，并通过选举机制产生新主节点（单主模式）。

        数据一致性保障：读写事务需经过集群多数节点（>N/2）确认后才能提交，避免数据分裂。

        弹性扩展：支持动态添加 / 移除节点，无需中断集群服务。

        两种运行模式：单主模式（仅 1 个可写节点）和多主模式（所有节点可写）。

1.2 组复制架构原理

组复制依赖以下核心组件：

        组通信系统（GCS）：负责节点间消息传递（如事务日志、心跳检测），基于 TCP 协议实现。

        一致性协议层：采用 Paxos 算法确保事务在集群中的顺序一致性。

        事务验证层：检测并发事务冲突（多主模式下），避免数据不一致。

工作流程简述：

        （1）主节点（单主模式）或任意节点（多主模式）接收写事务。

        （2）事务执行前生成预写日志（WAL），并广播至集群所有节点。

        （3）所有节点验证事务合法性（如无冲突），并通过一致性协议达成提交顺序共识。

        （4）多数节点确认后，事务在所有节点提交，确保全局一致。

1.3 单主模式组复制实现（实战步骤）

环境准备

IP地址server-id
候选主节点192.168.168.200200
从节点1192.168.168.129129
从节点2192.168.168.130

130

步骤1：所有节点基础配置（my.cnf）

[mysqld]
# 基础配置
server-id=200                  # 每个节点唯一（200/129/130）
datadir=/data/mysql
socket=/data/mysql/mysql.sock
pid-file=/data/mysql/mysql.pid# 二进制日志与GTID（MGR依赖GTID）
log_bin=/data/mysql/binlog
binlog_format=ROW              # 必须为ROW格式
log_slave_updates=ON           # 从库同步的事务写入自身binlog
gtid_mode=ON                   # 启用GTID
enforce_gtid_consistency=ON    # 强制GTID一致性# 组复制相关配置
transaction_write_set_extraction=XXHASH64  # 事务写入集提取算法
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"  # 集群UUID（自定义）
loose-group_replication_start_on_boot=OFF  # 不自动启动组复制
loose-group_replication_local_address="192.168.168.200:33061"  # 本节点组通信端口（每个节点修改IP）
loose-group_replication_group_seeds="192.168.168.200:33061,192.168.168.129:33061,192.168.168.130:33061"  # 集群种子节点
loose-group_replication_bootstrap_group=OFF  # 仅初始化集群时设为ON
loose-group_replication_single_primary_mode=ON  # 启用单主模式

        重启所有节点使配置生效：

systemctl restart mysqld

步骤2：创建组复制专用账户（所有节点执行）

        登录MySQL，创建用于节点间通信的账户：

-- 创建复制用户（允许所有集群节点访问）
CREATE USER 'grp_user'@'192.168.168.%' IDENTIFIED BY 'Grp@123';
-- 授予复制权限
GRANT REPLICATION SLAVE ON *.* TO 'grp_user'@'192.168.168.%';
-- 刷新权限
FLUSH PRIVILEGES;

步骤3：配置复制通道（所有节点执行）

        设置基于GTID的复制通道，用于组内事务同步：

-- 停止现有复制（若有）
STOP REPLICA;-- 配置组复制通道
CHANGE REPLICATION SOURCE TO
SOURCE_USER='grp_user',
SOURCE_PASSWORD='Grp@123',
SOURCE_AUTO_POSITION=1
FOR CHANNEL 'group_replication_recovery';

步骤4：安装组复制插件（所有节点执行）

-- 安装组复制插件
INSTALL PLUGIN group_replication SONAME 'group_replication.so';-- 验证插件是否安装成功
SHOW PLUGINS LIKE 'group_replication';

        输出示例（状态为ACTIVE表示成功）：

+-------------------+----------+--------------------+----------------------+---------+
| Name              | Status   | Type               | Library              | License |
+-------------------+----------+--------------------+----------------------+---------+
| group_replication | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+-------------------+----------+--------------------+----------------------+---------+

步骤5：初始化集群（仅在第一个节点执行）

        在 192.168.168.200（候选主节点）上引导集群：

-- 启动集群初始化（仅第一次执行）
SET GLOBAL group_replication_bootstrap_group=ON;-- 启动组复制
START GROUP_REPLICATION;-- 关闭初始化开关（避免重复初始化）
SET GLOBAL group_replication_bootstrap_group=OFF;

步骤6：添加其他节点到集群（129和130节点执行）

-- 启动组复制，自动加入集群
START GROUP_REPLICATION;

步骤7：验证集群状态

        -- 启动组复制，自动加入集群 START GROUP_REPLICATION;

SELECT * FROM performance_schema.replication_group_members;

        输出示例（单主模式下MEMBER_ROLE为 PRIMARY 的是主节点）：

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 200e5b9a-732b-11f0-971f-000c29d6adc7 | 192.168.168.200 |        3306 | ONLINE       | PRIMARY     | 8.0.40         |
| group_replication_applier | 129e5b9a-732b-11f0-971f-000c29d6adc7 | 192.168.168.129 |        3306 | ONLINE       | SECONDARY   | 8.0.40         |
| group_replication_applier | 130e5b9a-732b-11f0-971f-000c29d6adc7 | 192.168.168.130 |        3306 | ONLINE       | SECONDARY   | 8.0.40         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

1.4 单主模式故障转移测试

1.模拟主节点故障：在主节点（200）执行停机命令：

systemctl stop mysqld

2.查看集群状态：在从节点（129）执行：

SELECT * FROM performance_schema.replication_group_members;

        输出中会显示原主节点状态为UNREACHABLE，约 30 秒后集群自动选举新主（如 129 节点变为 PRIMARY）。

3.恢复原主节点：重启 200 节点后，自动以从节点身份加入集群：

systemctl start mysqld

        登录 200 节点的 MySQL，启动组复制：

START GROUP_REPLICATION;

        再次查看集群状态，200 节点角色变为 SECONDARY。

1.5 多主模式组复制配置（扩展）

        多主模式允许所有节点同时处理写事务，适合高并发写入场景，配置差异如下：

1.修改所有节点的my.cnf：

loose-group_replication_single_primary_mode=OFF  # 关闭单主模式（启用多主）
loose-group_replication_enforce_update_everywhere_checks=ON  # 强制多主更新检查

2.重启节点并重新初始化集群（参考单主模式步骤5-6）：

-- 在第一个节点执行
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;-- 其他节点执行
START GROUP_REPLICATION;

3.验证多主模式：所有节点的MEMBER_ROLE均为 PRIMARY：

SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;

1.6 组复制监控与维护

1.查看集群健康状态：

-- 集群成员状态
SELECT * FROM performance_schema.replication_group_members;-- 事务冲突统计（多主模式）
SELECT * FROM performance_schema.replication_group_member_stats;

2.动态添加节点：

-- 在新节点执行（参考步骤2-4配置后）
START GROUP_REPLICATION;

3.移除节点：

-- 在待移除节点执行
STOP GROUP_REPLICATION;

4.集群重启（全部节点故障后）：

-- 在任意一个节点重新引导集群
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;-- 其他节点直接启动
START GROUP_REPLICATION;

总结

        MySQL 组复制（MGR）通过分布式一致性协议实现了自动故障转移和数据一致性，单主模式适合读多写少场景，多主模式适合高并发写入。实际部署时需注意：

        节点数至少 3 个，确保多数派机制生效；

        网络延迟需控制在 100ms 以内，避免影响事务提交效率；

        定期监控集群状态，及时处理故障节点。

结合业务场景选择合适的高可用架构，可有效提升 MySQL 集群的稳定性和可靠性。

二、MySQL高可用之MHA（Master High Availability）

2.1 MHA核心特性与优势

        MHA 是针对 MySQL 主从复制架构的高可用解决方案，通过自动监控主库状态、实现故障检测与自动切换，核心特性包括：

        自动故障转移：主库宕机后 10-30 秒内完成新主库选举与切换。

        数据一致性保障：通过 binlog 补传机制减少数据丢失风险。

        零数据丢失：配合半同步复制可实现接近零数据丢失。

        低侵入性：无需修改 MySQL 现有配置，兼容各种主从架构。

        在线切换：支持手动触发主从切换（如主库升级维护）。

2.2 MHA架构原理

MHA 由两部分组成：

        MHA Manager：管理节点，负责监控集群状态、触发故障转移。

        MHA Node：部署在所有 MySQL 节点，提供 binlog 复制、故障检测等功能。

故障转移流程：

        1.监控阶段：Manager 通过 SSH 定期（默认 3 秒）向主库发送 ping 包检测存活状态。

        2.故障确认：连续 3 次 ping 失败后，Manager 通过其他从库确认主库是否真的宕机。

        3.选举新主：根据从库的日志同步进度（优先选择最接近主库的从库）选举新主。

        4.故障转移：隔离旧主库（如关闭 VIP、防火墙阻断）；提升新主库（执行reset slave all）；其他从库指向新主库（通过 relay log 补全差异）；应用层切换至新主库（如更新 VIP 指向）；

2.3 MHA实战部署（单主多从架构）

环境准备

IP地址主机名
MHA Manager192.168.168.201mha-manager
MySQL 主库192.168.168.200master
MySQL 从库 1192.168.168.129slave1
MySQL 从库 2192.168.168.130slave2

步骤1：配置SSH免密登录（关键）

MHA Manager 需要免密登录所有 MySQL 节点，MySQL 节点间也需要免密互通：

# 在MHA Manager节点生成密钥
[root@mha-manager ~]# ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa# 分发密钥到所有节点（包括自身）
[root@mha-manager ~]# for host in 192.168.168.200 192.168.168.129 192.168.168.130 192.168.168.201; dossh-copy-id -i ~/.ssh/id_rsa.pub root@$host
done# 验证免密登录
[root@mha-manager ~]# ssh 192.168.168.200 date

步骤2：安装MHA软件

所有节点安装MHA Node

# 安装依赖
[root@master ~]# yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager# 下载并安装node包
[root@master ~]# wget https://github.com/yoshinorim/mha4mysql-node/releases/download/v0.58/mha4mysql-node-0.58-0.el7.noarch.rpm
[root@master ~]# rpm -ivh mha4mysql-node-0.58-0.el7.noarch.rpm

MHA Manager节点额外安装Manager包

[root@mha-manager ~]# wget https://github.com/yoshinorim/mha4mysql-manager/releases/download/v0.58/mha4mysql-manager-0.58-0.el7.noarch.rpm
[root@mha-manager ~]# rpm -ivh mha4mysql-manager-0.58-0.el7.noarch.rpm

步骤3：配置MySQL权限

在主库创建 MHA 专用管理用户（从库会同步该用户）：

-- 创建管理用户（用于监控和故障转移）
CREATE USER 'mha_admin'@'192.168.168.%' IDENTIFIED BY 'Mha@123';
GRANT ALL PRIVILEGES ON *.* TO 'mha_admin'@'192.168.168.%' WITH GRANT OPTION;-- 确保主从复制用户已存在（参考1.2章节的rep用户）
FLUSH PRIVILEGES;

步骤4：配置MHA Manager

创建配置目录

[root@mha-manager ~]# mkdir -p /etc/mha/mysql_cluster
[root@mha-manager ~]# mkdir -p /var/log/mha/mysql_cluster

编写集群配置文件

# /etc/mha/mysql_cluster/mha.cnf
[server default]
# 管理用户
user=mha_admin
password=Mha@123
# 复制用户（主从同步用）
repl_user=rep
repl_password=rep123
# 工作目录
manager_workdir=/var/log/mha/mysql_cluster
# 日志文件
manager_log=/var/log/mha/mysql_cluster/manager.log
# SSH连接端口
ssh_port=22
# MySQL端口
mysql_port=3306
# 检测间隔（秒）
ping_interval=3
# 二次检查的从库数量
secondary_check_script=masterha_secondary_check -s 192.168.168.129 -s 192.168.168.130
# 故障转移后执行的脚本（如更新VIP）
master_ip_failover_script=/etc/mha/mysql_cluster/master_ip_failover[server1]
hostname=192.168.168.200
port=3306
# 主库故障后禁止自动启动
no_master=1[server2]
hostname=192.168.168.129
port=3306
# 候选主库权重
candidate_master=1[server3]
hostname=192.168.168.130
port=3306
candidate_master=1

步骤5：编写VIP切换脚本

创建master_ip_failover脚本实现虚拟 IP（VIP）自动漂移：

#!/usr/bin/perl
use strict;
use warnings FATAL => 'all';
use Getopt::Long;my ($command,          $ssh_user,        $orig_master_host,$orig_master_ip,   $orig_master_port, $new_master_host,$new_master_ip,    $new_master_port,  $new_master_user,$new_master_password
);# VIP配置
my $vip = '192.168.168.250/24';
my $key = '0';
my $dev = 'ens33';GetOptions('command=s'          => \$command,'ssh_user=s'         => \$ssh_user,'orig_master_host=s' => \$orig_master_host,'orig_master_ip=s'   => \$orig_master_ip,'orig_master_port=i' => \$orig_master_port,'new_master_host=s'  => \$new_master_host,'new_master_ip=s'    => \$new_master_ip,'new_master_port=i'  => \$new_master_port,
);exit &main();sub main {print "\n\nIN SCRIPT TEST====$command======\n\n";if ( $command eq "stop" || $command eq "stopssh" ) {my $exit_code = 1;eval {print "Disabling VIP on old master: $orig_master_host \n";&stop_vip();$exit_code = 0;};if ($@) {warn "Got Error: $@\n";exit $exit_code;}exit $exit_code;}elsif ( $command eq "start" ) {my $exit_code = 10;eval {print "Enabling VIP on new master: $new_master_host \n";&start_vip();$exit_code = 0;};if ($@) {warn $@;exit $exit_code;}exit $exit_code;}elsif ( $command eq "status" ) {print "Checking the Status of the script.. OK \n";exit 0;}else {&usage();exit 1;}
}sub start_vip() {`ssh $ssh_user\@$new_master_host \"ip addr add $vip dev $dev\"`;`ssh $ssh_user\@$new_master_host \"arping -I $dev -c 3 -s $vip 192.168.168.1 > /dev/null 2>&1\"`;
}sub stop_vip() {`ssh $ssh_user\@$orig_master_host \"ip addr del $vip dev $dev\"`;
}sub usage {print"Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

赋予执行权限：

[root@mha-manager ~]# chmod +x /etc/mha/mysql_cluster/master_ip_failover

步骤6：验证MHA环境

检查SSH连通性

[root@mha-manager ~]# masterha_check_ssh --conf=/etc/mha/mysql_cluster/mha.cnf

输出All SSH connection tests passed successfully.表示成功。

检查主从复制状态

[root@mha-manager ~]# masterha_check_repl --conf=/etc/mha/mysql_cluster/mha.cnf

输出MySQL Replication Health is OK.表示成功。

步骤7：启动MHA Manager

# 后台启动
[root@mha-manager ~]# nohup masterha_manager --conf=/etc/mha/mysql_cluster/mha.cnf > /var/log/mha/mysql_cluster/manager.log 2>&1 &# 查看状态
[root@mha-manager ~]# masterha_check_status --conf=/etc/mha/mysql_cluster/mha.cnf
mysql_cluster (pid: 1234) is running(0:PING_OK), master:192.168.168.200

2.4 故障转移测试

1.模拟主库故障：在主库（200）执行关机命令

[root@master ~]# systemctl stop mysqld

2.观察MHA日志：

[root@mha-manager ~]# tail -f /var/log/mha/mysql_cluster/manager.log

日志会显示：检测到主库故障 → 选举新主（如 129）→ 转移 VIP → 完成切换。

3.验证结果：

        查看VIP是否漂移到新主库：

[root@slave1 ~]# ip addr show ens33 | grep 192.168.168.250

        检查从库是否指向新主：

mysql> show replica status\G

2.5 MHA日常维护

1.手动切换主库（如主库升级）：

[root@mha-manager ~]# masterha_master_switch --conf=/etc/mha/mysql_cluster/mha.cnf \
--master_state=alive \
--new_master_host=192.168.168.129 \
--new_master_port=3306 \
--orig_master_is_new_slave

2.重启MHA Manager：

[root@mha-manager ~]# masterha_stop --conf=/etc/mha/mysql_cluster/mha.cnf
[root@mha-manager ~]# nohup masterha_manager --conf=/etc/mha/mysql_cluster/mha.cnf &

3.添加新从库：配置新从库与主库同步；修改 mha.cnf 添加新节点配置；重新检查并启动 MHA；

总结：

        MHA 通过简洁的架构实现了 MySQL 主从集群的高可用，适合对成本敏感且已有主从架构的场景。部署时需注意：

        严格配置 SSH 免密登录（核心前提）；

        配合半同步复制减少数据丢失；

        编写可靠的 VIP 切换脚本（关键环节）；

        定期测试故障转移流程确保可用性；

根据业务规模和一致性要求，可选择 MHA（低成本）、MGR（强一致）或 Percona XtraDB Cluster（高并发）作为高可用解决方案。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/web/96324.shtml
繁体地址，请注明出处：http://hk.pswp.cn/web/96324.shtml
英文地址，请注明出处：http://en.pswp.cn/web/96324.shtml

如若内容造成侵权/违法违规/事实不符，请联系英文站点网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

判别模型 VS 生成模型

判别模型 VS 生成模型

1. 判别模型（Discriminative Models）判别模型直接学习输入特征（X）与输出标签（Y）之间的映射关系，即直接对条件概率P(Y|X)进行建模。判别模型关注于如何区分不同类别的数据。特点：直接…
阅读更多...
代码随想录算法训练营第三十一天 | 合并区间、单调递增的数字

代码随想录算法训练营第三十一天 | 合并区间、单调递增的数字

合并区间： 这里还是先对左区间进行排序，判断重叠区间，首先判断是否存在元素，存在那么就将元素的第一个放到结果中，那么判断重叠就是当前元素的左区间和结果集里的最后元素的右区间进行判断，如果重叠&#x…
阅读更多...
EXCEL VBA 清空Excel工作表（Sheet）的方法

EXCEL VBA 清空Excel工作表（Sheet）的方法

1. 删除所有内容，但保留格式和对象 这种方法只会清除单元格的内容，不会影响格式和嵌入的图表或对象。 Sub ClearSheetContents()Worksheets("Sheet1").Cells.ClearContents End Sub2. 删除所有内容和格式，但保留对象 这种方法会删除…
阅读更多...
智能客户服务支持智能体

智能客户服务支持智能体

超越传统客服机器人。智能体可以深度查询知识库、调用订单系统API、甚至根据客户情绪灵活处理退货、退款、升级投诉等复杂流程。 案例： 客户说：“我上周买的鞋子尺码不对，想换货但是找不到订单页面了。” 智能体行动： ① 通过用户…
阅读更多...
【MySQL|第四篇】DQL语句（二）——数据查询语言

【MySQL|第四篇】DQL语句（二）——数据查询语言

4、排序分页：（1）排序：查询数据的时候进行排序，就是根据某个字段的值，按照升序或者降序的情况将记录显示出来语法： select col_name,... from tb_name order by col_name [asc|desc]注意事项&…
阅读更多...
百度文心X1.1发布！实测深度思考能力！

百度文心X1.1发布！实测深度思考能力！

文章目录背景模型实测效果事实性指令跟随智能体模型技术解读基准测试文心飞桨携手共进总结背景 9月9日，WAVE SUMMIT深度学习开发者大会上，百度首席技术官、深度学习技术及应用国家工程研究中心主任王海峰正式发布了文心大模型X1.1深度思考模型&#xff…
阅读更多...
基于Java+SpringBoot的B站评论系统架构设计与实践深度解析

基于Java+SpringBoot的B站评论系统架构设计与实践深度解析

基于JavaSpringBoot的B站评论系统架构设计与实践深度解析 前言 作为国内领先的视频分享平台，B站的评论系统承载着海量用户的实时互动需求。本文将从架构师角度，基于JavaSpringBoot技术栈，深度解析评论系统的技术实现方案、核心难点及扩展性设…
阅读更多...
赋能数字孪生：Paraverse平行云实时云渲染平台LarkXR，提供强大的API与SDK用于二次开发和深度集成

赋能数字孪生：Paraverse平行云实时云渲染平台LarkXR，提供强大的API与SDK用于二次开发和深度集成

在数字孪生渗透千行百业的今天，构建一个高保真、实时交互、可大规模访问的虚拟孪生世界已成为核心需求。然而，对于开发者而言，从零开始构建实时云渲染、海量模型加载、数据双向互通、多端适配、网页嵌套，平台定制化等底层技术难关…
阅读更多...
基于Nginx实现反向代理、负载均衡与动静分离完整部署指南

基于Nginx实现反向代理、负载均衡与动静分离完整部署指南

基于Nginx实现反向代理、负载均衡与动静分离完整部署指南 文章目录基于Nginx实现反向代理、负载均衡与动静分离完整部署指南一、架构规划与环境准备1.1 架构设计思路1.2 服务器规划1.3 环境依赖二、部署Nginx负载均衡器2.1 安装Nginx依赖包2.2 创建Nginx专用用户2.3 编译安装Ng…
阅读更多...
HTML5国庆网站源码

HTML5国庆网站源码

一. 网站概述 本国庆主题网站以弘扬爱国主义精神为核心，通过丰富多元的交互功能与视觉设计，打造沉浸式国庆体验空间。网站采用单页面架构，通过平滑滚动实现各模块的无缝衔接，涵盖首页、知识科普、互动体验等十大功能板块&#xf…
阅读更多...
MySQL收集processlist记录的shell工具mysql_collect_processlist

MySQL收集processlist记录的shell工具mysql_collect_processlist

文章目录安装指南日志文件内容日志分析参考1.简单检索2.统计不同状态的语句的数量3.按照时间统计注意事项仓库这是一个纯脚本工具，用于从MySQL的information_schema.processlist视图中定期收集数据并保存到本地日志文件。支持MYSQL5.7-9.4版本。 template copy fro…
阅读更多...
工业RFID现场网关模块：实现多协议互通，128台读写设备互连！

工业RFID现场网关模块：实现多协议互通，128台读写设备互连！

随着工业4.0进程加速，企业对生产系统集成度的需求不断增长。在工厂中常需整合不同品牌PLC、驱动器、机械臂、读写器等设备系统，这其中就会涉及到如Profinet、EtherNet/IP、EtherCAT、Modbus TCP、CC-LINK IE等不同通讯协议连接。虽可将部分设备直接与PLC…
阅读更多...
黑马点评高级篇第7节课 输入INFO replication 显示0个从节点，但是在7002节点又显示它已经是7001节点的从节点了

黑马点评高级篇第7节课 输入INFO replication 显示0个从节点，但是在7002节点又显示它已经是7001节点的从节点了

问题描述在黑马点评高级篇第七节课的这个位置​​​​​​，当我输入INFO replication 的时候下面本应该显示为connected_slaves: 2，但是我的显示的是0。然后当我切换到7002端口的节点时，又显示7002就是7001的从节点解决我看弹幕上说在7002和7…
阅读更多...
pcb线路板打样厂家有哪些？

pcb线路板打样厂家有哪些？

在电子制造产业升级浪潮中，PCB打样环节的效率与品质直接影响产品迭代速度。本文聚焦国内五家具备核心技术竞争力的PCB打样厂商，深度解析其差异化优势，为硬件开发者提供精准选型参考。猎板PCB作为国家高新技术企业，猎板PCB在高频高…
阅读更多...
【python实用小脚本-211】[硬件互联] 桌面壁纸×Python梦幻联动｜用10行代码实现“开机盲盒”自动化改造实录（建议收藏）

【python实用小脚本-211】[硬件互联] 桌面壁纸×Python梦幻联动｜用10行代码实现“开机盲盒”自动化改造实录（建议收藏）

1. 场景故事 “作为HR，我曾每天手动换壁纸提神，直到某天忙到忘记，结果被同事截图当‘黑历史’…” → 转折点：用Python调用Windows API写了个“随机壁纸机”，开机自启，每次登录都是新风景，现在截…
阅读更多...
集成学习 —— 梯度提升树GBDT、XGBoost

集成学习 —— 梯度提升树GBDT、XGBoost

目录 一、梯度提升树 1、残差提升树 Boosting Decision Tree 2、梯度提升树 Gradient Boosting Decision Tree 二、构建案例 1、 初始化弱学习器(CART树)： 2、 构建第1个弱学习器 3、 构建第2个弱学习器 4、 构建第3个弱学习器 5、 构建最终弱学习器 6、 构…
阅读更多...
【船类】监控录像下船舶类别检测识别数据集：近7k图像，6类，yolo标注

【船类】监控录像下船舶类别检测识别数据集：近7k图像，6类，yolo标注

监控录像下船舶类别检测识别数据集概述 数据集包含 6900监控录像下船舶类别图像，6个标注类别： 散货船、集装箱船、渔船、杂货船、矿砂船、客船 标注格式：yolo txt（格式可转，可直接训练） 标注工具&#…
阅读更多...
用户故事设计范式（As a... I want to... So that...）

用户故事设计范式（As a... I want to... So that...）

我们来详细解析一下用户故事（User Story），包括其结构、为什么重要、如何编写好的用户故事以及一个完整的示例。1. 用户故事的基本结构：三段式模板最经典和通用的用户故事模板就是您提到的三段式：As a [角色]:目的&…
阅读更多...
【OpenGL】LearnOpenGL学习笔记20 - 实例化 Instancing

【OpenGL】LearnOpenGL学习笔记20 - 实例化 Instancing

上接：https://blog.csdn.net/weixin_44506615/article/details/151156446?spm1001.2014.3001.5501 完整代码：https://gitee.com/Duo1J/learn-open-gl | https://github.com/Duo1J/LearnOpenGL 实例化 Instancing 以往当我们在场景中要大量绘制相同模型…
阅读更多...
MySQL主从不一致？DBA急救手册：14种高频坑点+3分钟定位+无损修复!

MySQL主从不一致？DBA急救手册：14种高频坑点+3分钟定位+无损修复!

MySQL「主从不一致」最常见的成因、快速定位思路以及可落地的修复手段 一、为什么会不一致？14 类高频场景类别典型表现/触发条件快速自检命令/日志1. 从库被写入业务或 DBA 直连从库 UPDATE/INSERTSHOW VARIABLES LIKE read_only 应为 ON2. 复制过滤规则主从 binlog…
阅读更多...
最新文章

Copyright @ 2022~2023