标签：ali 梳理 log 相关 syn jin 做了 set mys
由于阿里云策略问题，要求用户从经典网络中全部迁出，搬迁到他们设置的 VPC 网络中。这里的 VPC 大概指的是逻辑上的一个虚拟局域网。即使是实际上你的机器垮机房在阿里云的不同机房。但是他们仍然能从逻辑上属于一个 VPC。这次搬迁涉及到的主要问题是，目前手里的机器有很多都不太清楚在做什么，上面的服务是否重要，包括其中的管理以及是否最后还能将其启动起来。可以说是挤压了非常多的老债务，通过这次迁移需要一并还上。心里还是比较虚的。
由于这次迁移的主负责人并不是我 所以只用管好自己手中的业务就好了，还是轻松不少。提前了两天开始梳理手里面的十几台机器，按照如下格式做了记录。
Data10： 目前来看可以直接迁， 也不用手动起什么。谁关注什么业务再去启动。 Data08: 1. 离线库 MySQL 的启动 /usr/bin/mysql 可以使用命令 启动： service mysqld start 停止：service mysqld stop 重启：service mysqld restart 这个今天半夜来重新启动一下 查看状态：service mysqld status 2. Maxwell(从离线到 aliyun) 的重新启动。/usr/local/share/maxwell-1.10.3 启动：bin/maxwell --kafka_topic=sync_to_aliyun 停掉：直接在我的 tmux 里面停掉(这里是生产者随时停都可以)。 3. Apache Zeppelin 数据分析（这个可以停 需要自己启一下不在当日启动） 启动：work: bin/zeppelin-daemon.sh start xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
十几台每台机器做什么，都照此做了记录。这样可以比较清楚的看到哪些服务在本机器上跑着。如何启动，需要注意一些什么。另外单个机器上的梳理任务遵循从重要 -> 次要。
使用 htop 命令按照内存排序，将所有吃资源的服务先梳理出来。按照经验这些大家伙总是会占用着更多的资源，也会更加重要。
梳理的时候遇到一个小插曲，之前搭建 某3台机器上的 kafka 集群并不是我操作的。不是很清楚上面的 HA 配置情况。巧合的是当天上午因为某些奇怪的原因集群3台中的某一台挂了，我开始就默认了集群的 topic 有高可用设置，并没有特别在意。后来收到同步数据不一致的情况去看了集群配置才猛然发现完全没有设置 HA 的 topic ，每个 topic 的 partition 都只有一个副本。。。。。。 所以其中某个节点一挂， 其负责的那些 partition 中的数据就会丢失。赶紧先启动起来，并且把这个问题记录下来了。在迁移停机期间将 重要的 topic 都设置了高可用三备份。
另外在迁移 kafka 集群的时候还遇到一个问题，kafka 似乎在集群刚启动的时候会需要不少时间来同步一些信息，包括与 zookeeper 通讯之类的。当完成同步之后才能在 kafka 里面查询到 topic 和 group 相关的信息，在启动完成之前会执行 kafka 的相关命令可能会一直得不到响应，这点也需要注意一下。以下罗列最常用到的命令：
./kafka-consumer-groups.sh --bootstrap-server xxxxxxx:9092 --describe --group sync_group_20180321
./kafka-consumer-groups.sh --bootstrap-server xxxxxxx:9092 --list
./kafka-topics.sh --zookeeper xxxxx:2181 --list
./kafka-topics.sh --zookeeper xxxxx:2181 --describe
这种全部停机的迁移基本上都会放在对用户影响最少的时候来进行，例如晚上。晚上经常做事情的时候都不是很清楚了 所以我罗列了一个 checklist 单子。只要 step by step 照着这个执行，就能最大程度的保证一切按照计划和预期执行。
1. ??得到业务通知 数据库关机之后 Data05 06 07 上的 kafka 集群需要设置 备份为 3 份 默认分区改为 4 份。删除 topic 再重新创建 topic 为4个副本。 具体操作： 将 05 06 07 kafka config 中设置 num.partitions= 12 offsets.topic.replication.factor=3 transaction.state.log.replication.factor=3 transaction.state.log.min.isr=3 然后使用命令 ./kafka-consumer-groups.sh --bootstrap-server 10.171.97.1:9092 --describe --group sync_group_20180321 观察生产消费都已经停止。 2. ??当得到业务通知数据库开机这边可以迁移了 开始迁移数据的机器。 3. ??https://ecs.console.aliyun.com/?spm=5176.2020520001.aliyun_sidebar.aliyun_sidebar_ecs.311e4bd3VY5wLr#/server/region/cn-beijing 去该地址根据标签过滤属于 data 的机器。 4. ??从 data01 开始预约迁移。 右侧-> 更多 -> 网络和安全组 -> 预约迁移至专用网络 一共预约 16 台机器。 08 07 10 05 02 01 04 12 03 11 yanxishe01 研习社02 研习社服务器 06 5. ??阿里云 Hybird for MySQL 迁移到设置到 a 区。 迁移到 redis01 可用a区 6. ??如果没有意外发生 等待至预约重启时间，如果有问题中断流程。 aliyun 经典网络 -> vpc 迁移完成 7. ??检查 Hybird for MySQL 的请求地址是否有变化 如果有变化 需要改变相关库的地址。 地址未改变 8. ??从 data01 开始修改机器内网 ip地址 。右侧 -> 管理 -> 停止 -> 配置信息更多 -> 修改私有 ip 地址依次操作 16 台机器 9. ??根据文档 https://wiki.hundun.cn/pages/viewpage.action?pageId=20659409 挂载 data 所有机器上的相关磁盘 并且修改 /etc/fstab 文件至正确 并且 check 去每台已经修改完 ip 的机器上使用命令 Fdisk -l 查看需要挂载的硬盘名称。然后将该名字更新到 /etc/fstab 上并且取消注释 使用命令 mount /dev/xxxx /directory 即可 mount /dev/sdb1 /data 10. ??优先恢复 medivh 系统正常，去 data02 上使用命令 仅启动 zookeeper 脚本 kafka 会起来 Zookeeper 启动：./zookeeper-server-start.sh -daemon /usr/share/kafka/config/zookeeper.properties Kafka 启动：/usr/share/kafka/bin/kafka-server-start.sh -daemon /usr/share/kafka/config/server.properties 恢复 kafka 和 zookeeper 服务。 11. ??去 data05 06 07 上依次将 kafka 集群启动起来。 按照顺序依次启动 05 -> 06 ->07 的 zookeeper ./zkServer.sh start 启动 05 -> 06 -> 07 上的 kafka ./kafka-server-start.sh -daemon /opt/kafka/kafka_2.11-1.0.1/config/server.properties 观察消费情况 删除 sync_aliyun 主题 并且重新创建 sync_aliyun 主题 ./kafka-topics.sh --zookeeper 10.171.97.1:2181 --delete --topic sync_to_aliyun ./kafka-topics.sh --zookeeper 10.171.97.1:2181 --create --topic sync_to_aliyun --replication-factor 3 --partitions 12 12. ??去 data08 上恢复 该机器的 supervisor Root 权限下 python /usr/bin/supervisord -c /etc/supervisord.conf 然后 supervisorctl 恢复上面的 消费者服务 sync_maxwell_mysql:sync_to_data08mysql start 去 data05 将其生产者启动起来 Root 权限下 python /usr/bin/supervisord -c /etc/supervisord.conf 然后 supervisorctl 将所有生产者启动起来 并且进行 线上到离线库的验证 在线 -> 离线 check 流程完成。 13. ??启动 data08 上的 maxwell bin/maxwell --kafka_topic=sync_to_aliyun 生产者起起来 离线 -> 阿里云 需要 check 流程完成。 14. ??从 data01 开始 启动相关服务。 ??验证相关服务。
每完成以项就打勾确认，直到你完成所有的配置项，最后再看一眼 结束。
良好的计划和对业务的梳理可以让你在服务迁移的时候更加从容。这次搬迁过程中除了启动集群的时候稍微多花了一点时间以外，其他都是完全按照计划，整个过程非常平滑。
可见一般迁移之前的准备工作如果足够充分，可以让你在实施的时候事半功倍。
从 Aliyun 经典网络迁移到 Aliyun VPC 网络
标签：ali 梳理 log 相关 syn jin 做了 set mys
原文地址：https://www.cnblogs.com/piperck/p/9531202.html
