调度系统核心服务迁移方案演进 系统使用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查看所在目录，杀掉进程、删除相关文件夹

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

Memcache部署流程 建安装目录 mkdir -p /application/search/libeventmkdir -p /application/search/memcached安装libevent tar zxvf libevent-2.0.21-stable.tar.gzcd libevent-2.0.21-stable./configure -prefix= /application/search/libeventmakemake installtar zxvf memcached-1.4.21.tar.gz注：安装memcached时需要指定libevent的安装位置./configure -prefix=/application/search/memcached --with-libevent=/application/search/libeventmakemake instal启动memcached/application/search/memcached/bin/memcached -d -m 1024 -u search -l 172.16.0.6 -p 12015 -c 512 -P/application/search/searcher/memcached/bin/memcached 可执行程序路径11211 端口号1024m 分配1024M内存-d 在后台运行Memcached在实现分布集群部署时，Memcached服务端的之间是没有通讯的，服务端是伪分布式，实现分布式是由客户端实现的，客户端实现了分布式算法把数据保存到不同的Memcached 服务端。分布式缓存需考虑如下三点：1、缓存本身的水平线性扩展的问题。2、缓存大病罚下的本身性能问题。3、避免缓存的单点鼓掌问题。分布式缓存存在的问题：1、内存本身的管理问题。内存的分配，管理和回收机制。2、分布式管理和分布式算法。3、缓存键值管理和路由。