精选列表

搜索[初体验],共233篇文章
优秀的个人博客,低调大师

云原生边缘设备解决方案Akri on k3s初体验

作者: 涂家英,SUSE 资深架构师,专注 Cloud-Native 相关产品和解决方案设计,在企业级云原生平台建设领域拥有丰富的经验。 写在前面 k3s 是 SUSE 推出的为物联网和边缘计算构建的经过认证的 Kubernetes 发行版,它可以帮助用户在资源受限的场景下使用 kubernetes,并结合 SUSE Rancher 实现云边协同。 将 k3s 与微软开源的 kubernetes 边缘项目 Akri 结合使用,用户就拥有了在边缘环境发现和使用各种 IOT 设备的能力。 架构 Akri 目前是 CNCF 的一个开源项目,其功能简单地说就是可以根据配置自动地寻找到相应的 iot 设备,为其创建关联的工作负载,并且通过不断地检测实现工作负载的动态变化。引用一句官方的描述为:You name it, Akri finds it, you use it. 架构如下: 包含了 Controller 服务、Agent 服务和 Discovery Handlers 服务以及两个 CRD 资源。 具体的组件解析可以查看官方文档:https://docs.akri.sh/architecture/architecture-overview 下面我们通过一个示例来更好地理解 Akri 的工作方式。 体验 示例使用了官方提供的一个 OPC UA 温度计 Demo,OPC UA 是现在使用比较广泛的工业自动化通信协议,我们可以通过 Akri 自动发现使用 OPU CA 协议的温度计设备,并为其创建工作负载,采集和使用其产生的温度数据。 示例中体现的大致工作流程如下: 首先需要模拟出两台 OPC UA 的服务设备,然后在 k3s 集群上部署 Akri 服务,基础工作完成后: 向集群配置用于发现 OPC UA 设备的 CRD(Configuration) CRD 下发后,Akri 的相应 Discovery 服务会按照规则寻找 OPC UA 设备 在找到 OPC UA 设备后,Agent 服务会生成设备对应的 CRD(Instance),Controller 服务查看到 Instance CRD 资源后,将创建对应的工作负载 OPC UA 设备模拟 使用了一个.NET 类型的开源项目模拟实现 OPU CA 设备,项目地址为:https://gitee.com/leotuss/opcua-donet 克隆到本地后,需要修改以下文件: # /opcua-dotnet/Applications/ConsoleReferenceServer/Quickstarts.ReferenceServer.Config.xml文件第76、77行 将<node-ip style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;">替换为节点地址 #/opcua-dotnet/Applications/ReferenceServer/Quickstarts.ReferenceServer.Config.xml文件第77、78行 将<node-ip style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;">替换为节点地址</node-ip></node-ip>` Linux 要运行这个程序,需要安装.NET core 的 SDK 和 runtime 可以使用以下命令运行此程序: dotnet run --project /opcua-dotnet/Applications/ConsoleReferenceServer/NetCoreReferenceServer.csproj 运行后,可以看到如下提示: root@edge-iot1:~/opcua-dotnet/Applications/ConsoleReferenceServer# dotnet run --project NetCoreReferenceServer.csproj .Net Core OPC UA Reference Server opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer https://192.168.6.151:62540/Quickstarts/ReferenceServer/ Server started. Press Ctrl-C to exit... 至此程序运行成功,应用可以通过订阅opc.tcp://:62541/Quickstarts/ReferenceServer获得数据 安装 Akri 可以通过 Helm 安装 Akri: # 添加Akri repo helm repo add akri-helm-charts https://project-akri.github.io/akri/ # 部署Akri helm install akri akri-helm-charts/akri\ --setkubernetesDistro=k3s \ --setopcua.discovery.enabled=true 关于 kubernetesDistro 配置,Akri 依赖 crictl 跟踪 pod 信息,所以必须知道容器运行时 socket 的位置。目前 Akri 支持四种类型: 标准 kuberentes,对应配置为:--set kubernetesDistro=k8s k3s,对应配置为:--setkubernetesDistro=k3s microk8s,对应配置为:--set kubernetesDistro=microk8s 其它,对应配置为:--set agent.host.containerRuntimeSocket=/container/runtime.sock 关于 xxx.discovery.enabled 配置,Akri 目前支持三种设备发现: onvif:IP Cameras 的主流协议 opc ua:工业自动化通信协议 udev:linux 设备管理器 如我们需要 Akri 发现 onvif 设备,就可以配置--set onvif.discovery.enabled=true,配置后 Akri 会在集群中部署相应的 Discovery 服务,以 Daemonset 的方式运行,支持叠加部署,如需要发现上述三种类型设备,部署命令可以修改为: helm install akri akri-helm-charts/akri\ --setkubernetesDistro=k3s \ --setopcua.discovery.enabled=true\ --setonvif.discovery.enabled=true\ --setudev.discovery.enabled=true 部署完成后查看集群 Pods 可以看到: root@edge-k3s:~# kubectl get pods NAME READY STATUS RESTARTS AGE akri-controller-deployment-d4f7847b6-rlgrr 1/1 Running 11(25h ago) 4d2h akri-agent-daemonset-9s9m9 1/1 Running 10(25h ago) 3d23h akri-opcua-discovery-daemonset-tv84d 1/1 Running 8(25h ago) 3d17h 部署 CRD 使用 Akri 发现设备需要部署类型为 Configuration 的 CRD: apiVersion:akri.sh/v0 kind:Configuration metadata: name:akri-opcua-monitoring namespace:default spec: brokerProperties: IDENTIFIER:Thermometer_Temperature NAMESPACE_INDEX:"2" brokerSpec: brokerPodSpec: containers: - image:ghcr.io/project-akri/akri/opcua-monitoring-broker:latest name:akri-opcua-monitoring-broker resources: limits: '{{PLACEHOLDER}}':"1" cpu:30m memory:200Mi requests: '{{PLACEHOLDER}}':"1" cpu:9m memory:76Mi capacity:1 configurationServiceSpec: ports: - name:grpc port:80 protocol:TCP targetPort:8083 type:ClusterIP discoveryHandler: name:opcua discoveryDetails:|+ opcuaDiscoveryMethod: standard: discoveryUrls: -opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer/ -opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer/ applicationNames: action:Exclude items:[] name:opcua instanceServiceSpec: ports: - name:grpc port:80 protocol:TCP targetPort:8083 type:ClusterIP 需要关注的配置: spec.brokerProperties: 用于定义需要采集数据的 ID 信息,本演示中 opcua 程序中添加了IDENTIFIER:为Thermometer_Temperature和NAMESPACE_INDEX: "2"的数据输出,数据输出内容为 70-80 的随机数,并且在随机到 75 时,将 75 替换为 120 spec.brokerSpec.brokerPodSpec.containers.image: 设备对应工作负载的镜像,演示使用的是官方提供的镜像,作用是订阅 opcua 所产生的相应数据,此镜像是可以自定义的,实现更多可能 spec.capacity:针对设备的工作负载副本数量,用于实现工作负载高可用 spec.discoveryHandler: 这部分主要定义了发现 opuca 设备的规则,支持一些过滤规则 spec.configurationServiceSpec:Akri Controller 服务会为所有设备的工作负载创建一个总 svc,这段用于定义相应的 svc 的配置 spec.instanceServiceSpec: Akri Controller 服务会为每一个工作负载创建 svc,这段用于定义相应 svc 的配置 示例中可以看到 opuca 的发现规则是具体的服务地址,如果要支持批量的 opuca 设备发现,可以使用 Local discovery server(LDS),将 opcua 的设备注册到 LDS 中,然后在 discoveryUrls 配置中使用 LDS 的地址。采用 LDS 方式的话,可以实现过滤能力,如排除掉哪些 opcua 服务或者包含哪些 opcua 服务,示例如下: # 发现LDS中的所有opcua设备,除了<someserver style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;">以外</someserver> discoveryDetails:|+ opcuaDiscoveryMethod: standard: discoveryUrls: -opc.tcp://<lds服务器地址 style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;">:4840</lds服务器地址> applicationNames: action:Exclude items: - 将 akri-opcua-monitoring 的 crd 部署到集群后,可以通过kubectl get akric查看: root@edge-k3s:~/akric-crd# kubectl get akric NAME CAPACITY AGE akri-opcua-monitoring 1 2m13s 查看 Discovery 的服务日志可以看到,两个 opcua 设备已经被发现: [2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - found server : Quickstart Reference Server [2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - server has [UAString { value: Some("https://192.168.6.151:62540/Quickstarts/ReferenceServer/discovery") }, UAString { value: Some("opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer") }] DiscoveryUrls [2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_urls - Server at opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer/ responded with 1 Applications [2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - found server : Quickstart Reference Server [2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - server has [UAString { value: Some("https://192.168.6.152:62540/Quickstarts/ReferenceServer/discovery") }, UAString { value: Some("opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer") }] DiscoveryUrls [2022-11-10T08:26:26Z TRACE akri_opcua::discovery_handler] discover - found OPC UA server at DiscoveryURL opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer [2022-11-10T08:26:26Z TRACE akri_opcua::discovery_handler] discover - found OPC UA server at DiscoveryURL opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer 可以通过kubectl get akrii查看由 Agent 自动生成的 opcua 的 instance crd 资源: root@edge-k3s:~/akric-crd# kubectl get akrii NAME CONFIG SHARED NODES AGE akri-opcua-monitoring-7aa6fb akri-opcua-monitoring true ["edge-k3s"] 5m10s akri-opcua-monitoring-20f7e0 akri-opcua-monitoring true ["edge-k3s"] 5m9s` 于此同时,使用kubectl get pods可以查看到为设备自动创建的工作负载: NAME READY STATUS RESTARTS AGE akri-controller-deployment-d4f7847b6-rlgrr 1/1 Running 11 (27h ago) 4d4h akri-agent-daemonset-9s9m9 1/1 Running 10 (27h ago) 4d1h akri-opcua-discovery-daemonset-tv84d 1/1 Running 8 (27h ago) 3d19h edge-k3s-akri-opcua-monitoring-7aa6fb-pod 1/1 Running 0 6m44s <--- edge-k3s-akri-opcua-monitoring-20f7e0-pod 1/1 Running 0 6m43s <--- 部署数据展示服务 部署数据展示服务查看效果: kubectl apply -f https://raw.githubusercontent.com/project-akri/akri/main/deployment/samples/akri-anomaly-detection-app.yaml 部署完成后,查看一下展示服务 SVC 的 NodePort 端口: root@edge-k3s:~# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 5d6h akri-opcua-monitoring-7aa6fb-svc ClusterIP 10.43.152.214 <none> 80/TCP 13m akri-opcua-monitoring-svc ClusterIP 10.43.242.118 <none> 80/TCP 13m akri-opcua-monitoring-20f7e0-svc ClusterIP 10.43.22.196 <none> 80/TCP 13m akri-anomaly-detection-app NodePort 10.43.248.164 <none> 80:32007/TCP 7s <--- 访问 NodePort 端口,查看效果: 这个展示服务原理是通过连接工作负载的 SVC 获取工作负载采集到的设备数据,当值为 70-80 中任意数值时表示正常,用黑体展示;当值为 120 时表示异常,用红体展示 当设备下线时,Akri 会自动删除设备对应的工作负载,删除的时间大约为 5 分钟,以便应对可能出现的临时网络故障。 总 结 Akri 其实可以理解为是一种设备自动发现的框架,它可以通过云原生的方式帮助我们发现并使用 IOT 设备,目前支持 onvif、udev、opcua 三种类型。其它包括 Bluetooth、CoAP、IP、LoRaWAN、Zeroconf、acpid、MQTT 也正在开发中。 使用 k3s 可以帮助用户实现在边缘侧使用 kubernetes 的能力,通过 Akri 可以解决边缘场景下发现和使用设备的问题,这样用户就能将更多的精力专注在数据处理的应用上。

优秀的个人博客,低调大师

TiDB 之 TiCDC6.0 初体验

作者: JiekeXu 原文来源:https://tidb.net/blog/2dc4482b TiCDC 是一款 TiDB 增量数据同步工具,通过拉取上游 TiKV 的数据变更日志,具有将数据还原到与上游任意时刻一致的能力,同时提供开放数据协议(TiCDC Open Protocol),支持其他系统订阅数据变更,TiCDC 可以将数据解析为有序的行级变更数据输出到下游。 TiCDC 的系统架构如下图所示: TiCDC 运行时是一种无状态节点,通过 PD 内部的 etcd 实现高可用。TiCDC 集群支持创建多个同步任务,向多个不同的下游进行数据同步。 系统角色 TiKV CDC 组件:只输出 key-value (KV) change log。 o内部逻辑拼装 KV change log。 o提供输出 KV change log 的接口,发送数据包括实时 change log 和增量扫的 change log。 capture:TiCDC 运行进程,多个 capture 组成一个 TiCDC 集群,负责 KV change log 的同步。 o每个 capture 负责拉取一部分 KV change log。 o对拉取的一个或多个 KV change log 进行排序。 o向下游还原事务或按照 TiCDC Open Protocol 进行输出。 原理 原理:TiDB Server 负责接收 SQL,然后调用 TiKV 各个节点,然后输出自己节点的改变日志,然后将日志传到 TiCDC 集群,每个集群的 Capture 实际上为 TiCDC 节点,TiCDC 在内部逻辑拼装接收到的日志,提供输出日志的接口,发送到下游的 MySQL、Kafka 等。 每个 Capture 负责拉取一部分日志,然后自己排序,各个 capture 协同将自己接收的日志发送给capture 选择出来的owner,owner 进一步将日志排序,发送给目标下游端。 TiCDC 适用场景 TiCDC 适合源数据库为 TiDB,目标数据库支持 MySQL 兼容的任何数据库和 Kafka,同时 TiCDC Open Protocol 是一种行级别的数据变更通知协议,为监控、缓存、全文索引、分析引擎、异构数据库的主从复制等提供数据源。 数据库灾备:TiCDC 可以用于同构数据库之间的灾备场景,能够在灾难发生时保证主备集群数据的最终一致性,目前该场景仅支持 TiDB 作为主备集群。 数据集成:TiCDC 提供 TiCDC Canal-JSON Protocol,支持其他系统订阅数据变更,能够为监控、缓存、全文索引、数据分析、异构数据库的主从复制等场景提供数据源。 生产环境推荐配置 一般生产环境最低需要两台 16c 64G SSD 硬盘 万兆网卡的机器资源,如果是测试、学习环境,配置不需要这么高,也可以使用一个节点。 TiCDC环境部署 一般分两种情况:可以前期随 TiDB 一起部署,也可以后期进行扩容部署。 前期使用 tiup 部署 可以在 topology.yaml 文件中增加 tiup cluster deploy jiekexu-tidb v6.0.0 ./topology.yaml --user root -p cdc_servers 约定了将 TiCDC 服务部署到哪些机器上,同时可以指定每台机器上的服务配置。 gc-ttl:TiCDC 在 PD 设置的服务级别 GC safepoint 的 TTL (Time To Live) 时长,单位为秒,默认值为 86400,即 24 小时。 port:TiCDC 服务的监听端口,默认 8300 后期扩容 TiCDC 根据 保姆级分布式数据库 TiDB 6.0 集群安装手册 检查集群状态 tiup cluster status jiekexu-tidb 如果没有启动集群,需要先启动 tiup cluster start jiekexu-tidb 编辑扩容配置文件,准备将 TiCDC 节点 192.168.75.15/16 加入到集群中去. vim scale-out.yaml cdc_servers: - host: 192.168.75.15 gc-ttl: 86400 data_dir: /tidb-data/cdc-data/cdc-8300 - host: 192.168.75.16 gc-ttl: 86400 data_dir: /tidb-data/cdc-data/cdc-8300 加入 2 个 TiCDC 节点,IP 为 192.168.75.15/16,端口默认 8300,软件部署默认在 /tidb-deploy/cdc-8300 中,日志部署在 /tidb-deploy/cdc-8300/log 中,数据目录在 /tidb-data/cdc-data/cdc-8300 中。 使用 tiup 为原有 TiDB 数据库集群扩容 TiCDC 节点。 tiup cluster scale-out jiekexu-tidb scale-out.yaml -uroot -p [root@jiekexu1 ~]# tiup cluster scale-out jiekexu-tidb scale-out.yaml -uroot -p tiup is checking updates for component cluster ... Starting component `cluster`: /root/.tiup/components/cluster/v1.10.2/tiup-cluster scale-out jiekexu-tidb scale-out.yaml -uroot -p Input SSH password: + Detect CPU Arch Name - Detecting node 192.168.75.15 Arch info ... Done - Detecting node 192.168.75.16 Arch info ... Done + Detect CPU OS Name - Detecting node 192.168.75.15 OS info ... Done - Detecting node 192.168.75.16 OS info ... Done Please confirm your topology: Cluster type: tidb Cluster name: jiekexu-tidb Cluster version: v6.0.0 Role Host Ports OS/Arch Directories ---- ---- ----- ------- ----------- cdc 192.168.75.15 8300 linux/x86_64 /tidb-deploy/cdc-8300,/tidb-data/cdc-data/cdc-8300 cdc 192.168.75.16 8300 linux/x86_64 /tidb-deploy/cdc-8300,/tidb-data/cdc-data/cdc-8300 Attention: 1. If the topology is not what you expected, check your yaml file. 2. Please confirm there is no port/directory conflicts in same host. Do you want to continue? [y/N]: (default=N) y + [ Serial ] - SSHKeySet: privateKey=/root/.tiup/storage/cluster/clusters/jiekexu-tidb/ssh/id_rsa, publicKey=/root/.tiup/storage/cluster/clusters/jiekexu-tidb/ssh/id_rsa.pub + [Parallel] - UserSSH: user=tidb, host=192.168.75.16 + [Parallel] - UserSSH: user=tidb, host=192.168.75.14 + [Parallel] - UserSSH: user=tidb, host=192.168.75.15 + [Parallel] - UserSSH: user=tidb, host=192.168.75.13 + [Parallel] - UserSSH: user=tidb, host=192.168.75.12 + [Parallel] - UserSSH: user=tidb, host=192.168.75.11 + [Parallel] - UserSSH: user=tidb, host=192.168.75.17 + [Parallel] - UserSSH: user=tidb, host=192.168.75.17 + [Parallel] - UserSSH: user=tidb, host=192.168.75.17 + [Parallel] - UserSSH: user=tidb, host=192.168.75.17 + Download TiDB components - Download cdc:v6.0.0 (linux/amd64) ... Done + Initialize target host environments + Deploy TiDB instance - Deploy instance cdc -> 192.168.75.15:8300 ... Done - Deploy instance cdc -> 192.168.75.16:8300 ... Done + Copy certificate to remote host ……………………省略中间信息…………………… + Refresh components conifgs - Generate config pd -> 192.168.75.12:2379 ... Done - Generate config pd -> 192.168.75.13:2379 ... Done - Generate config pd -> 192.168.75.14:2379 ... Done - Generate config tikv -> 192.168.75.15:20160 ... Done - Generate config tikv -> 192.168.75.16:20160 ... Done - Generate config tikv -> 192.168.75.17:20160 ... Done - Generate config tidb -> 192.168.75.11:4000 ... Done - Generate config cdc -> 192.168.75.15:8300 ... Done - Generate config cdc -> 192.168.75.16:8300 ... Done - Generate config prometheus -> 192.168.75.17:9090 ... Done - Generate config grafana -> 192.168.75.17:3000 ... Done - Generate config alertmanager -> 192.168.75.17:9093 ... Done + Reload prometheus and grafana - Reload prometheus -> 192.168.75.17:9090 ... Done - Reload grafana -> 192.168.75.17:3000 ... Done + [ Serial ] - UpdateTopology: cluster=jiekexu-tidb Scaled cluster `jiekexu-tidb` out successfully 部署完成后检查集群状态,发现 TiCDC 已经部署到两节点了。我们看到 TiCDC 集群的 ID 为 192.168.75.15:8300, 192.168.75.16:8300,Status(状态)为 UP,表示 TiCDC 部署成功。 执行缩容操作 tiup cluster scale-in jiekexu-tidb --node 192.168.75.15:8300 这里仅下掉 75.15其中 --node 参数为需要下线节点的 ID。预期输出 Scaled cluster jiekexu-tidb in successfully 信息,表示缩容操作成功。 TiCDC 管理工具初尝试 cdc cli 是指通过 cdc binary 执行 cli 子命令,在以下接口描述中,通过 cdc binary 直接执行 cli 命令,PD 的监听 IP 地址为 192.168.75.12,端口2379。 使用 tiup ctl:v6.0.0 cdc 检查 TiCDC 的状态,如下: tiup ctl:v6.0.0 cdc capture list --pd=http://192.168.75.12:2379 命令中 --pd==http://192.168.75.12:2379,可以是任何一个 PD 节点,“is-owner”: true 代表当 TiCDC 节点为 owner 节点。为 false 代表备节点。 如果使用 TiUP 工具部署 TiCDC,那么则使用 TiUP 管理,命令可以写成 tiup cdc cli 数据同步准备 首先下游需要 MySQL 数据库,并为 MySQL 数据库( 端口号为 3306 )加入时区信息,创建数据库 jiekexu,并创建表 T1 ,注意不插入数据,如下操作: 192.168.75.12 已经安装好 MySQL5.7.38 数据库实例。 su – mysql mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql -S /mysql/data/mysql3306/socket/mysql3306.sock mysql -uroot -p -P 3306 -S /mysql/data/mysql3306/socket/mysql3306.sock create database jiekexu; use jiekexu; create table T1(id int primary key, name varchar(20)); select * from T1; 然后 TiDB 端数据库准备 create database jiekexu; use jiekexu; create table T1(id int primary key, name varchar(20)); select * from T1; 创建同步任务 cd /tidb-deploy/cdc-8300/bin ./cdc cli changefeed create --pd=http://192.168.75.12:2379 --sink-uri="mysql://root:root@192.168.75.12:3306/" --changefeed-id="simple-replication-task" --sort-engine="unified" [WARN] some tables are not eligible to replicate, []model.TableName{model.TableName{Schema:"test", Table:"t1", TableID:0, IsPartition:false}} Could you agree to ignore those tables, and continue to replicate [Y/N] Y Create changefeed successfully! ID: simple-replication-task Info: {"sink-uri":"mysql://root:root@192.168.75.12:3306/","opts":{"_changefeed_id":"sink-verify"},"create-time":"2022-06-30T00:14:25.821140534+08:00","start-ts":434246584426037251,"target-ts":0,"admin-job-type":0,"sort-engine":"unified","sort-dir":"","config":{"case-sensitive":true,"enable-old-value":true,"force-replicate":false,"check-gc-safe-point":true,"filter":{"rules":["*.*"],"ignore-txn-start-ts":null},"mounter":{"worker-num":16},"sink":{"dispatchers":null,"protocol":"","column-selectors":null},"cyclic-replication":{"enable":false,"replica-id":0,"filter-replica-ids":null,"id-buckets":0,"sync-ddl":false},"scheduler":{"type":"table-number","polling-time":-1},"consistent":{"level":"none","max-log-size":64,"flush-interval":1000,"storage":""}},"state":"normal","error":null,"sync-point-enabled":false,"sync-point-interval":600000000000,"creator-version":"v6.0.0"} 说明: –changefeed-id:同步任务的 ID,格式需要符合正则表达式 [1]+(-[a-zA-Z0-9]+)*$。如果不指定该 ID,TiCDC 会自动生成一个 UUID(version 4 格式)作为 ID。 –sink-uri:同步任务下游的地址,需要按照以下格式进行配置,目前 scheme 支持 mysql/tidb/kafka/pulsar。 –sort-engine:指定 changefeed 使用的排序引擎。因 TiDB 和 TiKV 使用分布式架构,TiCDC 需要对数据变更记录进行排序后才能输出。该项支持 unified(默认)/memory/file: unified:优先使用内存排序,内存不足时则自动使用硬盘暂存数据。该选项默认开启。 memory:在内存中进行排序。 不建议使用,同步大量数据时易引发 OOM。 file:完全使用磁盘暂存数据。已经弃用,不建议在任何情况使用。 查看同步任务 ./cdc cli changefeed list --pd=http://192.168.75.12:2379 [ { "id": "simple-replication-task", "summary": { "state": "normal", "tso": 434246659203137537, "checkpoint": "2022-06-30 00:19:03.469", "error": null } } ] 注意:“state”: “normal” : 表示任务状态正常。 “tso”: 434246659203137537: 表示同步任务的时间戳信息。 “checkpoint”: “2022-06-30 00:19:03.469” :表示同步任务的时间。 详细查询复制任务信息 { "info": { "sink-uri": "mysql://root:root@192.168.75.12:3306/", "opts": { "_changefeed_id": "sink-verify" }, "create-time": "2022-06-30T00:14:25.821140534+08:00", "start-ts": 434246584426037251, "target-ts": 0, "admin-job-type": 0, "sort-engine": "unified", "sort-dir": "", "config": { "case-sensitive": true, "enable-old-value": true, "force-replicate": false, "check-gc-safe-point": true, "filter": { "rules": [ "*.*" ], "ignore-txn-start-ts": null }, "mounter": { "worker-num": 16 }, "sink": { "dispatchers": null, "protocol": "", "column-selectors": null }, "cyclic-replication": { "enable": false, "replica-id": 0, "filter-replica-ids": null, "id-buckets": 0, "sync-ddl": false }, "scheduler": { "type": "table-number", "polling-time": -1 }, "consistent": { "level": "none", "max-log-size": 64, "flush-interval": 1000, "storage": "" } }, "state": "normal", "error": null, "sync-point-enabled": false, "sync-point-interval": 600000000000, "creator-version": "v6.0.0" }, "status": { "resolved-ts": 434246739838369793, "checkpoint-ts": 434246739313819649, "admin-job-type": 0 }, "count": 0, "task-status": [ { "capture-id": "9163a533-97e2-4b64-838a-139c70ea89f3", "status": { "tables": null, "operation": null, "admin-job-type": 0 } }, { "capture-id": "6155ee47-1e22-4369-b2b7-670c43b11b46", "status": { "tables": null, "operation": null, "admin-job-type": 0 } } ] } 数据同步测试 对于同步任务进行验证,登录 TiDB 数据库,查询刚刚创建的 jiekexu 数据库下面的表 T1,并且插入三行数据,如下所示: 源端插入数据 insert into T1 values(1,'jiekexu'); insert into T1 values(2,'jiekexu dba'); insert into T1 values(2,'jiekexu tidb'); select * from T1; 登录 MySQL 数据库,查询 jiekexu 数据库下面的表 T1,发现数据库已经同步过去,如下所示: mysql> select * from T1; +----+--------------+ | id | name | +----+--------------+ | 1 | jiekexu | | 2 | jiekexu dba | | 3 | jiekexu tidb | +----+--------------+ 3 rows in set (0.00 sec) 源端更新、删除数据 mysql> update T1 set name='jiekexu tidb dba' where id=3; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from T1; +----+------------------+ | id | name | +----+------------------+ | 1 | jiekexu | | 2 | jiekexu dba | | 3 | jiekexu tidb dba | +----+------------------+ 3 rows in set (0.00 sec) mysql> delete from T1 where id=1; Query OK, 1 row affected (0.01 sec) mysql> select * from T1; +----+------------------+ | id | name | +----+------------------+ | 2 | jiekexu dba | | 3 | jiekexu tidb dba | +----+------------------+ 2 rows in set (0.01 sec) 目标端 MySQL 端查看 mysql> select * from T1; +----+------------------+ | id | name | +----+------------------+ | 1 | jiekexu | | 2 | jiekexu dba | | 3 | jiekexu tidb dba | +----+------------------+ 3 rows in set (0.00 sec) mysql> select * from T1; +----+------------------+ | id | name | +----+------------------+ | 2 | jiekexu dba | | 3 | jiekexu tidb dba | +----+------------------+ 2 rows in set (0.00 sec) 源端添加、修改、删除列 alter table T1 add addr varchar(50); alter table T1 modify name varchar(32); alter table t1 add changeTime datetime default now(); Alter table t1 drop column changeTime; 目标端查看也能正常同步。 源端新建表数据插入测试 CREATE TABLE `Test` ( `id` int(11) NOT NULL, `name` varchar(32) DEFAULT NULL, `addr` varchar(50) DEFAULT NULL, PRIMARY KEY (`id`) ); insert into Test values(1,'jiekexu','beijing'); 目标端 MySQL 端查看 停止同步任务 ./cdc cli changefeed --help Manage changefeed (changefeed is a replication task) Usage: cdc cli changefeed [flags] cdc cli changefeed [command] Available Commands: create Create a new replication task (changefeed) cyclic (Experimental) Utility about cyclic replication list List all replication tasks (changefeeds) in TiCDC cluster pause Pause a replication task (changefeed) query Query information and status of a replication task (changefeed) remove Remove a replication task (changefeed) resume Resume a paused replication task (changefeed) statistics Periodically check and output the status of a replication task (changefeed) update Update config of an existing replication task (changefeed) ./cdc cli changefeed pause --pd=192.168.75.12:2379 --changefeed-id simple-replication-task ./cdc cli changefeed pause --pd=http://192.168.75.12:2379 --changefeed-id simple-replication-task 注意:pause 停止任务时,pd 后面也可以不跟 http:// 协议,不会报错。 恢复同步任务 ./cdc cli changefeed resume --pd=http://192.168.75.12:2379 --changefeed-id simple-replication-task 注意:Pd 后面需要跟 http 协议,不然会报错。 删除同步任务 ./cdc cli changefeed remove --pd=http://192.168.75.12:2379 --changefeed-id simple-replication-task TiCDC 的限制 有效索引的相关要求 TiCDC 只能同步至少存在一个有效索引的表,有效索引的定义如下: 主键 (PRIMARY KEY) 为有效索引。 同时满足下列条件的唯一索引 (UNIQUE INDEX) 为有效索引: 索引中每一列在表结构中明确定义非空 (NOT NULL)。 索引中不存在虚拟生成列 (VIRTUAL GENERATED COLUMNS)。 TiCDC 从 4.0.8 版本开始,可通过修改任务配置来同步没有有效索引的表,但在数据一致性的保证上有所减弱。具体使用方法和注意事项参考同步没有有效索引的表。 暂不支持的场景 目前 TiCDC 暂不支持的场景如下: 暂不支持单独使用 RawKV 的 TiKV 集群。 暂不支持在 TiDB 中创建 SEQUENCE 的 DDL 操作和 SEQUENCE 函数。在上游 TiDB 使用 SEQUENCE 时,TiCDC 将会忽略掉上游执行的 SEQUENCE DDL 操作/函数,但是使用 SEQUENCE 函数的 DML 操作可以正确地同步。 对上游存在较大事务的场景提供部分支持,详见 TiCDC 是否支持同步大事务?有什么风险吗? 参考链接: https://docs.pingcap.com/zh/tidb/v6.0/ticdc-overview https://learn.pingcap.com/learner/course/30002

优秀的个人博客,低调大师

MAUI初体验:爽

只是记录,只是Hello World体验,别期望太高。 1. 前言 经过几个小时折腾,Maui环境终于安装好了,先上Hello World截图: 1.1 MAUI Windows上 1.2 MAUI Android上 2. 今早看到一个群聊推送 点击链接可以看推送:爱奇艺 Preview 上架微软 Win11 应用商店:全新 WinUI 3 版本,软件界面大变(附下载地址) 爱奇艺使用的WinUI 3可能和MAUI Windows开发使用的WinUI不同?请知道的留言解惑: 3. MAUI环境安装前介绍 MAUI-Check:这是安装MAUI的检测工具,在安装的过程中可能会出现一些问题 这是安装过程: 可能会出现如下异常: 不要担心,下面是安装介绍文章(不翻译了,累),只要你有科学上网工具,多来几次,有可能会成功的,哈哈 3. 正式安装MAUI环境 Mac 参考链接:https://subscribe.packtpub.com/getting-started-with-microsoft-net-maui/ 站长卡在工作负载安装失败,多次都没成功,mac暂时放弃了,后面再研究 有兴趣的看看这些视频学习下: https://www.youtube.com/watch?v=eF5YcpyzQIo&t=350s https://xam.com.au/installing-net-maui-preview/ https://www.banditoth.hu/2021/12/29/setup-net-maui-project-on-macos/ Windows 站长主要看的这个链接安装环境,折腾了几个小时成功了 https://subscribe.packtpub.com/getting-started-with-microsoft-net-maui/ 4. 结束 上面的链接如果不行,你也可以多搜索谷歌其他文章,安装教程网上很多,最好用谷歌,看看油管视频。 昨天和今天只是体验下MAUI开发体验,热重载加载很快,MAUI大有可为,私下站长可能开发桌面应用就上MAUI了(当然移动APP也是),不过暂时就不研究MAUI了,下半年或者明年再研究MAUI。 今天发文只是报告一下体验MAUI hello world,完结。

资源下载

更多资源
Oracle Database,又名Oracle RDBMS

Oracle Database,又名Oracle RDBMS

Oracle Database,又名Oracle RDBMS,或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统,系统可移植性好、使用方便、功能强,适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的、适应高吞吐量的数据库方案。

Apache Tomcat7、8、9(Java Web服务器)

Apache Tomcat7、8、9(Java Web服务器)

Tomcat是Apache 软件基金会(Apache Software Foundation)的Jakarta 项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。因为Tomcat 技术先进、性能稳定,而且免费,因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可,成为目前比较流行的Web 应用服务器。

Eclipse(集成开发环境)

Eclipse(集成开发环境)

Eclipse 是一个开放源代码的、基于Java的可扩展开发平台。就其本身而言,它只是一个框架和一组服务,用于通过插件组件构建开发环境。幸运的是,Eclipse 附带了一个标准的插件集,包括Java开发工具(Java Development Kit,JDK)。

Java Development Kit(Java开发工具)

Java Development Kit(Java开发工具)

JDK是 Java 语言的软件开发工具包,主要用于移动设备、嵌入式设备上的java应用程序。JDK是整个java开发的核心,它包含了JAVA的运行环境(JVM+Java系统类库)和JAVA工具。