调度系统核心服务迁移方案演进 系统使用Zookeeper进行主从服务选举，对于频繁更新数据库的服务S1和S2，迁移操作需要确保高可用性并且不容忍数据丢失。首先，对数据库进行扩展，引入DB3。要确保DB3的数据与主数据库DB1和从数据库DB2完全一致，需要执行库锁操作。由于服务对数据库的操作不支持等待或失败重试，所以无法对主数据库进行锁定。因此，考虑了以下方案：1.对DB2进行锁库，此时DB2是静态的flush tables with read lock;2.将DB2的历史数据导入DB3主：bin/mysqldump -urecom recom -p >recom.sql 从：bin/mysql -u recom -p recom < recom.sql3.将DB3的Master指向DB2show master status; change master to master_host='10.*.*.*',master_user='un',master_password='pwd123',master_log_file='/opt/mysql_data/binlog.000068',master_log_pos=117844696; start slave; show slave status \G;4.然后解锁DB2，此时延迟同步的数据会同步到DB2，DB2再同步到DB3，从而保证了三个数据库完全一致unlock tables;使用同样的方式，可以扩展DB4，形成链式复制。在将服务配置切换到新的数据库时，主库的切换可能会带来一些问题。由于每个服务都有独立的配置，无法同时对所有服务进行配置更新。后续如果引入NACOS，通过配置热更新可以使迁移变得更加简单。因此，在修改某个服务的主库之前，需要考虑以下情况：假设S1和S2的配置分别为DB1和DB2。现在要切换S2的配置。当S2的主库发生改变后，在切换其他服务的主库之前，可能会出现同时向DB1和DB2/DB3进行更新的情况。这意味着DB1更新的数据会同步到DB2和DB3，但是DB2和DB3更新的数据无法同步到DB1。如果一个请求到达S2并在DB2/DB3中插入了一条数据，接下来的请求到达S1时，当尝试更新上一个请求插入的数据时，就会发生异常。因此，链式复制可以满足数据库的扩展需求，但无法满足服务的扩展需求。在迁移过程中，存在一个关键时间点，其中两个服务可能同时对不同的数据库进行更新操作。然而，一旦更新了主从复制链中间的库，上游数据库将无法同步到最新的数据。如果希望在迁移过程中保持服务的高可用性，必须解决这个问题。需要确保无论哪个服务更新了其中一个数据库，其他数据库都能感知到这个变化。因此，考虑将链式的主从MySQL连接成一个环形结构。在实现这一点时，需要考虑以下两个问题：{card-describe title="问题"}1.在更新数据时，担心在环路上可能会导致死循环的问题。通过进行调研，发现MySQL提供了良好的支持，不会出现这种问题。2.另一个需要考虑的问题是自增主键的冲突。假设在DB1插入了一条数据，在这条数据同步之前，又在DB2插入了一条数据。这样，这两条不同数据的自增主键可能会相同。当DB1和DB2之间通过环路复制传递新增数据时，就会发生主键冲突的情况。{/card-describe}针对上述问题，需要找到解决方案来确保数据同步和主键唯一性。为了解决这个问题，可以通过设置auto_increment_offset和auto_increment_increment来控制不同库之间的自增偏移量和步长。这样，就能够在任何时间点将服务指向环形结构中的任意两个库，从而完成迁移过程。MySQL相关命令：启动和初始化 bin/mysqld --defaults-file=/opt/mysql/my.cnf --initialize --user=root --basedir=/opt/mysql --datadir=/opt/mysql_data bin/mysqld_safe --defaults-file=/opt/mysql/my.cnf --user=root & 获取root密码 cat errorlog.err | grep root@localhost 重置密码和授权 bin/mysql -u root -p set password for 'root'@'localhost' = password(''); CREATE USER 'recom'@'%' IDENTIFIED BY 'recom@123'; GRANT ALL PRIVILEGES ON *.* TO 'recom'@'%' IDENTIFIED BY 'recom@123' WITH GRANT OPTION; flush privileges; 其他命令 stop slave; reset slave all; bin/mysqladmin -uroot -p shutdown

CPU使用率突增问题排查记录-木马攻击 1.使用top或者ps -aux | sort -k4nr | head -n 10命令查看占用cpu较高的进程2.使用systemctl status 19084查看Main PID，可以看到是定时任务3.使用cd /proc/681ls -ail查看所在目录，杀掉进程、删除相关文件夹

JVM垃圾收集行为分析方法 尽管某些监控工具，如：jvisualvm，可以实时提供垃圾收集图表和指标，但它们并没有提供GC行为完整的详细信息，GC日志是研究垃圾收集行为的最佳信息来源。启用GC日志 可以通过指定以下JVM参数来启用GC日志：Java 8及以下版本-XX:+PrintGCDetails -Xloggc:<gc-log-file-path> Example: -XX:+PrintGCDetails -Xloggc:/opt/tmp/myapp-gc.logJava 9及以上版本-Xlog:gc*:file=<gc-log-file-path> Example: -Xlog:gc*:file=/opt/tmp/myapp-gc.log注意事项 一般需要观察24小时的GC日志，这样就会同时看到高流量和低流量的情况。 建议从生产环境中收集GC日志，因为垃圾收集行为受流量模式的影响很大，在测试环境中很难模拟生产流量。我们进行2次测试：基线测试——使用JMeter工具在没有启用垃圾收集GC日志的情况下运行应用程序20分钟，同时有200个并发用户。GC日志启用测试——使用相同的JMeter脚本运行应用程序并启用垃圾收集GC日志，持续时间为20分钟，同时有200个并发用户。对比结果如下：如图所示，CPU和内存消耗没有明显差异，同样，平均响应和事务吞吐量也没有明显差异，通过实验可以看出，GC日志在生产服务器中增加的开销可以忽略不计。分析工具 捕获GC日志后，可以使用以下免费工具之一来分析GC日志：1.GCeasy 2.IBM GC & Memory visualizer 3.HP Jmeter4.Garbage Cat

Redis集群部署方案 系统包安装 配置操作系统yum 源安装以下系统包安装gcc：yum install gcc安装zlib：yum install zib安装ruby：yum install ruby 2.0以上安装rubygems：yum install rubygemsRedis 安装 在redis 官网https://redis.io/download下载 redis-3.2.9.tar.gz拷贝redis-3.2.9.tar.gz 到/application/search解压 tar –zxvf redis-3.2.9.tar.gz安装 cd src && make && make test && make install修改配置 进入cd /application/search/ redis-3.2.9复制 cp redis.conf redis6400.conf修改 redis6400.conf 里面的参数port 6400 --端口maxmemory 2g –内存大小cluster-enabled yes –开启集群模式dir /data0/redis 数据文件存放位置详细配置请见 服务器上配置启动停止 以 172.16.0.9 6400为例:启动：redis-server redis6400.conf停止： redis-cli –c –h 172.16.0.9 –p 6400 shutdown构建集群 在三台172.16.0.9，172.16.0.8 172.16.0.6 安装完成redis以后构建三主三从的高可用redis集群在任一台机器执行命令：/application/search/redis-3.2.9/src/redis-trib.rb create --replicas 2 172.16.0.9:6400 172.16.0.9:6401 172.16.0.9:6402 172.16.0.6:6500 172.16.0.6:6501 172.16.0.6:6502 172.16.0.8:6600 172.16.0.8:6601 172.16.0.8:6602

kubeadm部署k8s问题汇总 1.kubectl get cs查看组件状态kube-scheduler和kube-controller-manager显示unhealthy配置文件路径：/etc/kubernetes/manifests/scheduler.conf/etc/kubernetes/manifests/controller-manager.conf去掉--port=0这个设置，然后重启sudo systemctl restart kubelet2.报错open /run/flannel/subnet.env: no such file or directory查看各个节点，包括master 节点是否有/run/flannel/subnet.env，内容应该是类似如下：FLANNEL_NETWORK=10.244.0.0/16FLANNEL_SUBNET=10.244.0.1/24FLANNEL_MTU=1450FLANNEL_IPMASQ=true没有则创建3.no space left on device错误修改虚机启动的引导项 grub 中的cgroup.memory=nokmem，让机器启动时直接禁用 cgroup的 kmem 属性修改/etc/default/grub 为：GRUB_CMDLINE_LINUX="crashkernel=auto net.ifnames=0 biosdevname=0 intel_pstate=disable cgroup.memory=nokmem"生成配置：/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg 路径中可能是grub重启机器：reboot验证：cat /sys/fs/cgroup/memory/kubepods/burstable/pod//memory.kmem.slabinfo 无输出即可。4.解决Google浏览器不能打开kubernetes dashboard方法mkdir key && cd key #生成证书 openssl genrsa -out dashboard.key 2048 openssl req -new -out dashboard.csr -key dashboard.key -subj '/CN=192.168.246.200' openssl x509 -req -in dashboard.csr -signkey dashboard.key -out dashboard.crt #删除原有的证书secret kubectl delete secret kubernetes-dashboard-certs -n kube-system #创建新的证书secret kubectl create secret generic kubernetes-dashboard-certs --from-file=dashboard.key --from-file=dashboard.crt -n kube-system #查看pod kubectl get pod -n kube-system #重启pod kubectl delete pod <pod name> -n kube-system