@petelin #9 关于使用什么数据类型存储时间，网上真的什么说法都有。下面是我找到的一些资料，希望对看到这个主题的人有所帮助。对于使用 BIGINT 存储时间，我暂时不太清楚那样子做的利弊，可能之后会尝试一下，看看它的利弊到底是什么。

integer - Should I use a big INT or regular INT in MySQL to store a timestamp? - Stack Overflow - https://stackoverflow.com/questions/2031228/should-i-use-a-big-int-or-regular-int-in-mysql-to-store-a-timestamp

mysql - DATETIME VS INT for storing time? - Stack Overflow - https://stackoverflow.com/questions/43705935/datetime-vs-int-for-storing-time

Should I use the datetime or timestamp data type in MySQL? - Stack Overflow - https://stackoverflow.com/questions/409286/should-i-use-the-datetime-or-timestamp-data-type-in-mysql

Adam D'Angelo's answer to What is the best way to store a timestamp in MySQL? - Quora - https://www.quora.com/What-is-the-best-way-to-store-a-timestamp-in-MySQL/answer/Adam-DAngelo

@xupefei #4
@xuanbg #5
@rockyou12 #6

通过在 connection URL string 中显式地设置时区（ serverTimezone=Asia/Shanghai ）解决了，原因是时区的不一致导致的，默认的时区应该是 UTC−05:00 。

Setting the MySQL JDBC Timezone In Spring Boot | Baeldung - https://www.baeldung.com/mysql-jdbc-timezone-spring-boot#param

@xupefei #1 `docker exec -it some-mysql mysql -u root -pmy-secret-pw`，然后执行`select now();`，其结果为`2020-08-22 20:19:13`。

`docker exec -it some-mysql mysql -u root -pmy-secret-pw`，然后执行`select now();`，其结果为`2020-08-22 20:19:13`。

@Itach1 #2

https://stackoverflow.com/questions/21317006/spring-boot-parent-pom-when-you-already-have-a-parent-pom--#comment44077262_21318359

https://stackoverflow.com/a/47954088/5232255

@SoloCompany #1 我希望它的 parent 是内部的，而不是 Spring Boot 的，所以采用了<scope>import</scope>这种方式。现在的话，就是自己显示地设置 plugin 的版本。

@samin 你说“ 由于 `binlog` 日志的原因，MySQL 的默认事务隔离级别是可重复读”，可以详细说明一下吗？具体是什么原因导致默认事务隔离级别为可重复读？

MySQL Bugs: #45670: Secondary auto-incremented primary fields on replicas end up with wrong value - https://bugs.mysql.com/bug.php?id=45670 说明了这个问题，也给出了解决方法，但是并没有说明为什么。

如果有人知道为什么的话，分享一下，提前谢谢了。

@guyskk0x0 #12 如果是数据库解决冲突，那当然可以，但是就像“Designing Data-Intensive Applications - CHAPTER 5 Replication - Leaderless Replication - Detecting Concurrent Writes - Last write wins (discarding concurrent writes)”中所说的“LWW achieves the goal of eventual convergence, but at the cost of durability: if there are several concurrent writes to the same key, even if they were all reported as successful to the client (because they were written to w replicas), only one of the writes will survive and the others will be silently discarded.”。我一直都是在强调数据库解决冲突的弊端。


@guyskk0x0 #6 我不觉得你前面所说的跟后面所说的是统一的，你前面说“没有合并那就应当有一个 client 失败”、“如果不合并数据就不一致了，所以必须有一个失败”，后面你却说“在 client 解决冲突”。

@guyskk0x0 但是人更明白应该怎么处理冲突，而不是数据库，你觉得呢？我在 Android 和 iOS 并发修改了我的年龄，数据库怎么选择一个最终值呢？

@guyskk0x0 #8 没错，是 CRDT，conflict-free replicated data type，“Merging concurrently written values”中讲了很多种方式，CRDT 是其中一种。但是这里怎么使用 CRDT 呢？

“没有合并那就应当有一个 client 失败”， 如果不合并数据就不一致了，所以必须有一个失败。

我不同意你所说的“没有合并那就应当有一个 client 失败”。本主题的合并操作是让 client 去解决，比如说第 4 步时，client 2 知道 cart 有两个值，分别为[milk]和[eggs]，它想继续加 ham，于是它合并了两个并发写的值[milk]和[eggs]，然后加上 ham，最后将[eggs, milk, ham]发给数据库。根本不需要实现“Last write wins (discarding concurrent writes)”，“Designing Data-Intensive Applications - CHAPTER 5 Replication - Leaderless Replication - Detecting Concurrent Writes - Last write wins (discarding concurrent writes)”也讲了它所存在的问题。

我不同意你所说的“如果不合并数据就不一致了”，不一致是指多个 replicas 的数据不一致，合并并发写的值跟不一致没有太大关系。如果有两个 replicas，分别为 r1 和 r2 （ Multi-Leader Replication ）。client 1 向 r1 执行 set k 1，client 2 并发向 r1 执行 set k 2，最后 r1 保留了 k 的两个值，就算 r1 不执行合并操作，那么只要 r2 也达到了“k 有两个值，分别为 1 和 2”这种状态，那就是一致的。

期待你的回复。

@guyskk0x0 #6

在“Designing Data-Intensive Applications - CHAPTER 5 Replication - Leaderless Replication - Detecting Concurrent Writes - Merging concurrently written values”中讲了怎么合并并发写的值，具体内容你可以看一下，这里就不贴出来了。

我还有几个疑问：
1. “如果有合并那就是 CRDT”是什么意思？
2. “没有合并那就应当有一个 client 失败”是指“不支持并发写”吗？这不就违背了 Multi-Leader Replication 和 Leaderless Replication 的初衷吗？

@limboMu #1 可以具体解释一下以下两点吗？我不太明白你想表达的意思。

1. 这样就可以在同一个 replica 中知道使用哪个值来来覆盖，至于 replica3-5 有可能是就没收到写入。也有可能是因为延迟，总之集群返回了一个统一的值。可能这也是 leaderless replication 没法保证强一致性的原因之一。（具体解释这一整段，可以的话，用例子描述一下）
2. 还有就是有的 leaderless replication 是有一个错值回改的操作。（可以具体解释以下错值回改吗？）

@guyskk0x0 #3 其实你说的跟我问的不太一样，你所说的“通过版本号实现的乐观并发控制”是不支持并发写的，即不支持“client 1 update table set value=101, version=2 where key= k and version=1”和“client 2 update table set value=102, version=2 where key= k and version=1”并发，只有一个先执行的 client 才会成功，后面的一个会被忽略。

而这种并发写是 Multi-Leader Replication 和 Leaderless Replication 的根本，我的问题也是关于 Leaderless Replication 如何处理并发写的。

@ekoeko 其实更严格来说，client 2 是不知道 client 1 和它并发的，它只是知道返回了多个值，出现了并发，但是它不知道具体是和哪个 client 。或许更加合理的方式是说数据库知道哪个版本跟哪个版本并发了。你觉得呢？

在“Designing Data-Intensive Applications - CHAPTER 5 Replication - Multi-Leader Replication - Multi-Leader Replication Topologies”中，介绍了三种不同 replication topologies：1. circular topology 2. star topology 3. all-to-all topology 。

它说“A problem with circular and star topologies is that if just one node fails, it can interrupt the flow of replication messages between other nodes, causing them to be unable to communicate until the node is fixed. The topology could be reconfigured to work around the failed node, but in most deployments such reconfiguration would have to be done manually. The fault tolerance of a more densely connected topology (such as all-to-all) is better because it allows messages to travel along different paths, avoiding a single point of failure.”，也就是说如果你继续采用 circular topology 的话，如果其中一个节点失败了，你可以重新配置 topology，你也可以选择容错性更好的 all-to-all topology 。

当然不同的 topologies 都有各自的优缺点，具体的话，你可以看一下“Designing Data-Intensive Applications”这本书。

顺便说一下，你这个根本不是主从同步，而是 Multi-Leader Replication 。

@xsm1890 #9 说实话，这条语句真的一点意义都没有。
@sdfqwe 是你自己可以制造出来的吗？

@sdfqwe 你的表为什么是这样子的？

1. nodeId 已经是 PRIMARY KEY 了，为什么还要定义一个多余的索引 nodeid 呢？
2. 为什么不直接叫 id 和 parentId 呢？ nodeId 不会有什么业务含义吧？
3. 为什么城市表会有层级关系的呢？

@sdfqwe #4 那就可以完全解释了，PRIMARY 和 nodeid 两个 index 相关的列都是 nodeid 。