timestamp不可用的原因是binlog日志文件被删除了,但没有重启mysql服务. 只配置个timestamp,会根据binlog.index文件去扫描整个的日志文件然后找到对应的时间戳附近位点信息.可通过以下两个命令验证是否能找到起始位点信息 找endPosition show master status, 找startPosition show binlog events limit 1

另外,还有可能是没有权限执行 show binlog events limit 1 和 show master status语句

原回答者Github用户 changeyoung2015

这可能是因为你的MySQL实例没有启用二进制日志（Binary Logging）或者启用了Binlog但没有正确配置位点信息导致的。

要获取二进制日志位点信息，需要首先确保MySQL实例已经启用二进制日志（Binary Logging）功能。在MySQL配置文件（my.cnf）中，需要确保以下参数被正确设置：

启用二进制日志功能

log-bin=mysql-bin

指定二进制日志格式为“ROW”

binlog-format=ROW

指定二进制日志的记录格式为“ROW”（可选）

binlog-row-image=FULL 配置完毕后，重启MySQL实例使配置生效。

如果MySQL实例已经启用了Binlog，但你仍然无法获取到位点信息或者添加上journalName，则可能是因为你没有正确配置主从复制关系。在MySQL主库上，需要通过命令向从库授权，并指定主库的二进制日志名称和位置信息。例如：

mysql> GRANT REPLICATION SLAVE ON . TO 'slave_user'@'%' IDENTIFIED BY 'password'; mysql> FLUSH PRIVILEGES; mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000357 | 19867324 | test | | +------------------+----------+--------------+------------------+

mysql> UNLOCK TABLES; 上述命令将向所有的从库授权，然后通过“SHOW MASTER STATUS”命令获取当前主库的位点信息，“File”字段为二进制日志的名称，“Position”字段为当前位置。

在MySQL从库上，需要配置复制线程以接收主库的操作记录，并将主库日志的位置信息保存到从库的配置文件中。配置文件中需要设置的项包括：从库的唯一ID、主库的IP地址和端口、主库的二进制日志名称和位置信息，例如：

server-id = 2 replicate-do-db = test relay-log = /var/lib/mysql/mysql-relay-bin relay-log-index = /var/lib/mysql/mysql-relay-bin.index relay-log-info-file = /var/lib/mysql/mysql-relay-bin.info master-info-file = /var/lib/mysql/master.info replicate-ignore-tables = mysql.* read-only = 1 log-slave-updates = 1 在配置文件中，“server-id”字段为从库的唯一ID，“replicate-do-db”字段为需要复制的数据库，“relay-log”字段为中继日志的名称，“relay-log-index”字段为中继日志索引文件的名称，“master-info-file”字段为保存主库信息的文件名，“read-only”字段为从库是否只读。

配置完成后，重启MySQL实例使配置生效。

如果你使用了正确的位点信息，但无法同步数据，则可能是因为主从复制线程发生了错误。需要在从库上执行“SHOW SLAVE STATUS”命令，查看复制线程的状态。如果“Slave_IO_Running”和“Slave_SQL_Running”字段的值都为“YES”，则表示复制线程正常运行。否则，需要根据代码less/error message调查复制线程发生错误的原因，并进行修复。

根据您提供的信息，我了解到您在使用自定义位点信息时遇到了一些问题。首先，您提到尝试使用{"timestamp":1578448679000}作为自定义位点信息，但无法获取到位点信息或添加上journalName，这可能是因为自定义位点信息必须包含journalName和position两个参数，否则无法识别位点信息。

其次，您提到使用{"journalName":"mysql-bin.000357","position":579216722}才可以正常同步数据，这是因为在 MySQL 中，位点信息由journalName和position两个参数组成，用于标识二进制日志的位置。如果您只提供了timestamp参数，Otter 是无法识别该位点信息的。

最后，如果您想自定义位点信息，可以使用以下格式：{"journalName":"mysql-bin.000357","position":579216722}，其中journalName和position分别代表二进制日志的名称和偏移量。请注意，您必须确保自定义位点信息的正确性，否则可能会导致数据同步失败。

由于Otter无法正确解析您提供的自定义位点信息导致的。具体来说，当您使用自定义位点信息时，Otter可能无法正确识别位点信息，并且不会将其用于数据同步。

为了解决这个问题，您可以尝试以下方法：

检查自定义位点信息的格式：请确保您提供的自定义位点信息格式正确。特别是，确保位点信息中包含必需的字段，例如journalName、timestamp和position。您可以参考MySQL文档或其他资源，以了解自定义位点信息的正确格式。

检查时间戳格式：请确保您提供的时间戳格式正确。时间戳应该是以毫秒为单位的整数值。您可以尝试使用不同的时间戳格式或值，并检查是否可以获取位点信息。

检查Otter配置：请检查您的Otter配置，确保它已正确设置，并且可以正确处理自定义位点信息。您可以尝试重新配置Otter，以确保它已正确设置。

尝试使用其他位点信息：如果您无法使用自定义位点信息，请尝试使用其他位点信息，例如默认的位点信息或其他有效的位点信息。您可以参考MySQL文档或其他资源，以了解如何获取有效的位点信息。

根据描述，自定义位点为{"timestamp":1578448679000}时无法获取到位点信息或添加上journalName。可能原因是该方式只指定了时间戳，没有指定具体的binlog文件名和位置信息。在没有具体指定binlog文件名和位置信息的情况下，MySQL无法精确地定位到指定时间戳的binlog日志。

而使用{"journalName":"mysql-bin.000357","position":579216722}的方式，则同时指定了binlog文件名和位置信息，MySQL可以根据这些信息精确地定位到相应的binlog文件和位置，从而实现正常的同步。

因此，建议在自定义位点时，同时指定具体的binlog文件名和位置信息，以确保MySQL可以精确地定位到指定的binlog日志。