@statement 其实我是没怎么看的，因为它只说了应该怎么做，但是没有解释为什么这么做好，为什么这么做不好。

@PopRain
@nekolr

我明白你们所说的，将不常用字段放在附加表可以让一页可以存储主表更多的纪录。可能我没有表达清楚我的问题，我最大的疑问是为什么要将 varchar 换为 text 呢？它们的表现基本是一样的。

@windghoul #2
@whileFalse #3

我想确认一下我理解的是不是正确的。--network=host 不行是因为 macOS 不支持，单纯使用-p ${i}:${i} -p $((${i} + 10000)):$((${i} + 10000))替换--network=host 不行是因为 redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 中的 127.0.0.1 （因为它们这三个容器都有自己的“动态”IP 地址）。对吗？

@yanyueio #1
@skai0dev #2

通过 @palfortime 在“MySQL 时间“不正确”问题 - V2EX”的回答 - https://www.v2ex.com/t/700563#reply15，我明白了为什么“在 connection URL string 中设置时区”会将所设置时区的时间存储到 MySQL ？明白了到底是哪里进行这样的处理的？。

在 https://github.com/mysql/mysql-connector-j/blob/79a4336f140499bd22dd07f02b708e163844e3d5/src/main/protocol-impl/java/com/mysql/cj/protocol/a/NativeProtocol.java#L2228 中，会获取到 connection URL string 中所设置的 serverTimezone，最后会设置 serverSession 的 serverTimeZone 。

@skai0dev #2 我有点不太理解“Override detection/mapping of time zone. Used when time zone from server doesn't map to Java time zone”，可以具体解释一下吗？谢谢。

@palfortime 我不太明白你所说的“mysql 默认认为 CST 是美国那个时区”，我已经设置了时区为 Asia/Shanghai 了。

@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 是有一个错值回改的操作。（可以具体解释以下错值回改吗？）