rpu*_*ant 2 mysql data-synchronization
我正在做一个项目，在该项目中，客户需要一个在线和一个离线应用程序。离线应用程序数据将手动同步到链接到 Web 应用程序的在线数据库。
数据库是MySQL，部分功能需要在线也可以离线使用。假设没有互联网访问权限的任何用户都将使用离线应用程序。一旦他完成了他的工作，并且可以访问互联网，他将通过单击将他的所有工作/数据同步到在线数据库。
我知道如何将数据推送到在线数据库，但这里的复杂性在于如何按顺序维护记录的索引/主键，而不丢失任何数据或不匹配任何数据。
用户将离线数据同步到在线时，如何按顺序维护主键？
计划 A：您让您的客户全力以赴开发代码以跟踪差异、避免重复密钥、上传数据等。
计划 B：多源复制（至少在 MariaDB 中可用）。
使用多源，每台离线笔记本电脑都可以成为“大师”。“在线服务器”是一个 Slave。所有写入都必须在 Master(s) 上完成。无法写入在线 Slave 应该不是问题，如果需要，只需在 HQ 添加一个额外的、集中的、离线的 Master。
至于 dup 键——您必须设计架构以避免任何类似的问题。这可能意味着 noAUTO_INCREMENT或FOREIGN KEYS。这可能意味着每个离线 Master 都有单独的表（或单独的数据库），用于任何不能没有会导致麻烦的东西。但是，这意味着在每次连接后都有某种解析代码。（上传只是复制做它的事情。）
计划 C：NDB 集群。这是在 MySQL 下可用的显着不同的引擎。设置很复杂。但是，它提供了一种不同的复制模型——“最终一致性”。而不是挂在 dup 键（等）上，你提供了在这种情况下做什么的规则。当复制导致冲突时，这些规则会自动应用。
方案D：Galera Cluster（内置于MariaDB 10.x；可手动安装在MySQL上）——通过这种集群技术，“节点”可以来来去去；当它们重新连接时，它们会自动恢复同步。但是...需要始终有一个法定人数，即超过 50% 的在线人数。尽管您可以写入任何节点，但不能写入不属于仲裁的节点。
计划 E：说服客户保持联系。或者在断开连接时不做任何写入。在这种情况下，离线机器可以是一个只读的 Slave。写入必须等待连接到远程主机。
注意：在任何情况下，您都应该在编写应用程序时明确关注哪些应用操作需要写入，哪些可以是只读的。建议您尽可能拥有两个单独的连接——一个用于写入和关联读取，一个用于普通读取。这将有助于您选择的任何计划。
我推荐哪个？我对你的情况听得不够多，无法说出哪个。