调度系统核心服务迁移方案演进

系统使用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.sql

3.将DB3的Master指向DB2

show 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连接成一个环形结构。在实现这一点时，需要考虑以下两个问题：

针对上述问题，需要找到解决方案来确保数据同步和主键唯一性。为了解决这个问题，可以通过设置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