【 使用环境 】生产环境
【 OB or 其他组件 】ob
【 使用版本 】 4.2.1-10BP
【问题描述】
已知ob集群遵循Paxos 协议。 写入半数以上副本成功才成功。
而具体做法是， 主副本写入成功后。将redo日志同步到 从副本。 从副本将redo日志落盘成功就返回成功了。
那么请问如果 从副本仅落盘redo日志。这时候立即在从副本执行查询操作。 能查询到最新的数据吗。
按照paxos协议。理论上 主从同步延迟无限接近0. 毕竟集群内的机器都在内网，各个从副本执行完同步操作的时间基本一致。
但从实际体验来看。
当代码逻辑为
写主副本 + 读从副本。
第二次读有较大概率读到 旧数据。主从副本之间的数据同步延迟是远大于ms级别，甚至超过1s的。
那么是否从副本如果仅仅落盘redo日志， 对于从副本的查询来说，新数据暂时还没合并的sstable上，是不是也是无法查询到的
根据文档库中的信息，可以对您的问题进行如下解答：
在 OceanBase 数据库中，主副本（Leader）生成 Redo 日志后，会通过 Paxos 协议将日志同步到从副本（Follower）。从副本接收到 Redo 日志并落盘后，会回放这些日志以更新内存中的 MemTable。只有当 Redo 日志被回放到 MemTable 后，查询才能看到最新的数据。
依据的文档内容包括：
因此，如果从副本仅完成了 Redo 日志的落盘，但尚未完成回放操作（即将日志应用到 MemTable），那么此时查询从副本是无法看到最新数据的。
您提到在实际体验中，主从副本之间的数据同步延迟可能超过 1 秒。这种现象可以通过以下几点解释：
此外，OceanBase 的设计原则是优先保证写入的高可用性和强一致性，而不是追求读取的低延迟。因此，在某些场景下，从副本的查询可能会返回旧数据。
关于您提到的 SSTable 和 MemTable：
如果您希望减少主从副本之间的延迟，可以考虑优化硬件配置（如使用高性能 SSD）或调整系统参数（如增加日志回放线程数）。具体方法可以参考官方文档或联系 OceanBase 技术支持团队获取更多建议。
具体信息可参考以下文档:
根据文档库中的信息，调整日志回放线程数可以通过设置租户级别的参数 log_restore_concurrency 来实现。以下是具体说明和操作步骤：
log_restore_concurrency
ALTER SYSTEM SET 语句修改。注意：
log_restore_concurrency 设置为 0 时，日志恢复工作线程数会自适应调整为租户的 max_cpu 数量。依据的文档名称及段落标题：
log_restore_concurrency -> 使用说明
log_restore_concurrency -> 属性说明
在 OceanBase 数据库中，可以使用以下 SQL 查询当前租户的 log_restore_concurrency 参数值：
SHOW PARAMETERS LIKE 'log_restore_concurrency';
如果需要手动调整日志回放线程数，可以通过以下 SQL 语句进行修改：
ALTER SYSTEM SET log_restore_concurrency = <目标值> TENANT = <租户名>;
例如，将日志回放线程数设置为 16：
ALTER SYSTEM SET log_restore_concurrency = 16 TENANT = sys;
修改完成后，再次执行以下命令以确认参数值已更新：
SHOW PARAMETERS LIKE 'log_restore_concurrency';
如果您还有其他问题或需要进一步优化，请随时提问！
更多信息请查看:
根据文档库中的信息，统计 Redo 日志从落盘到完成回放的平均时间差需要结合 OceanBase 数据库内部的监控和日志机制。以下是实现这一目标的具体方法和步骤：
Redo 日志从生成到回放完成涉及以下关键时间点：
这两个时间点的差值就是您需要统计的“Redo 日志落盘到完成回放的平均时间差”。
OceanBase 提供了一些系统视图来帮助监控 Redo 日志的状态和性能指标。以下是可能用到的视图：
__all_virtual_clog_stat
该视图记录了 Clog（Commit Log，即 Redo 日志）的相关统计信息，包括日志的生成、落盘和回放状态。
submit_timestamp：日志提交的时间戳。persisted_timestamp：日志落盘的时间戳。replayed_timestamp：日志回放完成的时间戳。通过这些字段可以计算出日志从落盘到回放完成的时间差。
gv$ob_log_stat
该视图提供了全局范围内的日志统计信息，包括日志的生成、同步和回放情况。
log_submit_time：日志提交时间。log_persist_time：日志落盘时间。log_replay_time：日志回放完成时间。要统计 Redo 日志从落盘到完成回放的平均时间差，可以通过以下 SQL 查询实现：
SELECT
AVG(replayed_timestamp - persisted_timestamp) AS avg_replay_delay
FROM
__all_virtual_clog_stat
WHERE
tenant_id = <租户ID> -- 替换为实际租户ID
AND svr_ip = '<服务器IP>' -- 替换为实际服务器IP
AND svr_port = <服务器端口>; -- 替换为实际服务器端口
replayed_timestamp - persisted_timestamp：计算单条日志从落盘到回放完成的时间差。AVG()：对所有日志的时间差求平均值。如果您正在使用 OceanBase Cloud Platform (OCP)，可以直接通过其内置的监控功能查看 Redo 日志的性能指标。OCP 提供了丰富的图表和报表功能，能够直观地展示日志落盘和回放的延迟情况。
通过查询系统视图 __all_virtual_clog_stat 或 gv$ob_log_stat，您可以计算 Redo 日志从落盘到完成回放的平均时间差。此外，使用 OCP 等监控工具也可以更方便地获取这些指标。如果需要进一步优化日志回放性能，可以考虑调整相关参数（如 log_restore_concurrency），并结合实际业务场景进行调优。
如果您还有其他问题，请随时提问！
检索到的文档如下:
@论坛小助手
4.2.1版本oceanbase，无表 __all_virtual_clog_stat。
且gv$ob_logstat无字段 log_persist_time、log_replay_time
根据您的反馈，__all_virtual_clog_stat 表和 gv$ob_log_stat 视图在 OceanBase 4.2.1 版本中确实不包含您提到的字段（如 persisted_timestamp、replayed_timestamp、log_persist_time 和 log_replay_time）。在这种情况下，我们需要寻找其他方法来间接统计 Redo 日志从落盘到完成回放的平均时间差。
以下是替代方案的详细说明：
gv$ob_log_stat 和其他监控指标虽然 gv$ob_log_stat 不直接提供 log_persist_time 和 log_replay_time 字段，但它可以用来查看日志流的状态和副本同步情况。结合其他系统视图或监控工具，您可以估算 Redo 日志的回放延迟。
SELECT
tenant_id,
partition_id,
is_in_sync,
last_submit_log_scn,
last_submit_log_ts,
last_replay_log_scn,
last_replay_log_ts
FROM
gv$ob_log_stat;
last_submit_log_ts：表示最后提交的日志时间戳。last_replay_log_ts：表示最后回放的日志时间戳。is_in_sync：表示副本是否同步（TRUE 或 FALSE）。通过计算 last_replay_log_ts - last_submit_log_ts，可以粗略估计日志从提交到回放的时间差。需要注意的是，last_submit_log_ts 并不完全等同于日志落盘时间，但可以作为近似值。
如果您正在使用 OceanBase Cloud Platform (OCP) 或其他监控工具，可以通过以下方式获取更精确的 Redo 日志延迟数据：
OCP 提供了丰富的性能监控功能，能够直观地展示日志落盘和回放的延迟情况。
__all_tenant_clog_stat 或类似视图在某些版本中，OceanBase 提供了其他系统视图来记录 Clog 的状态。例如，__all_tenant_clog_stat 可能包含与日志落盘和回放相关的统计信息。
SELECT
tenant_id,
svr_ip,
svr_port,
clog_disk_usage,
clog_replay_latency
FROM
__all_tenant_clog_stat;
clog_replay_latency：表示日志回放的延迟（单位为毫秒）。svr_ip 和 svr_port：表示服务器的 IP 和端口。通过查询该视图，您可以直接获取日志回放的延迟数据。
如果上述方法均不可用，您可以尝试通过业务逻辑手动计算 Redo 日志的回放延迟。具体步骤如下：
write_time）。read_time）。read_time - write_time，得到从写入到查询的延迟。需要注意的是，这种方法仅能估算整体延迟，无法区分日志落盘和回放的具体时间差。
由于 OceanBase 4.2.1 版本中缺少直接统计 Redo 日志落盘到回放时间差的字段，您可以尝试以下方法：
gv$ob_log_stat 的 last_submit_log_ts 和 last_replay_log_ts 字段进行粗略估算。__all_tenant_clog_stat 或类似视图中的 clog_replay_latency 字段。如果您需要进一步优化日志回放性能，可以考虑调整相关参数（如 log_restore_concurrency），并结合实际业务场景进行调优。
如果有其他问题，请随时提问！
详情请参考:
根据文档库中的信息，max_ob_tenant_log_sync_delay 监控指标的定义如下：
max_ob_tenant_log_sync_delay 是 OceanBase 数据库中用于监控租户日志同步的最大延迟时间。该指标具体指的是 Redo 日志从主副本生成到从副本完成落盘的时间差，并不包括从副本完成 Redo 日志回放的时间。
依据的文档内容包括：
文档片段 10：在 OceanBase 的备份架构中提到，日志归档的工作由日志流的 Leader 副本负责，按照日志流备份日志是 Log Entry 级别的物理备份。日志备份的周期默认为 2 分钟，提供了准实时的备份能力。这里明确说明了日志同步是指从主副本到从副本的日志落盘过程，而不包含日志回放的时间。
max_ob_tenant_log_sync_delay 仅衡量日志同步这一阶段的延迟，不包含日志回放的时间。如果您需要监控日志回放的延迟，可以参考其他指标，例如 clog_replay_latency 或者通过系统视图如 __all_tenant_clog_stat 获取相关信息。
max_ob_tenant_log_sync_delay 指的是 Redo 日志从主副本同步到从副本并完成落盘的时间延迟，不包括从副本完成日志回放的时间。如果需要全面了解日志从生成到查询可见的整体延迟，您需要结合日志同步和日志回放的相关指标进行分析。
如果有其他问题，请随时提问！
详情请参考:
根据文档库中的信息，gv$sysstat 视图中包含了许多系统级别的统计指标，其中包括 redo log replay time。以下是关于该字段单位的详细说明：
redo log replay time 表示 Redo 日志回放所花费的时间。具体来说，它是从 Redo 日志被读取并应用到内存中的 MemTable 所消耗的时间。
根据 OceanBase 数据库的惯例以及相关视图的设计，gv$sysstat 中的统计值通常以 微秒 (μs) 为单位。因此，redo log replay time 的值也是以 微秒 为单位。
您可以使用以下 SQL 查询来查看 redo log replay time 的值：
SELECT
name,
value
FROM
gv$sysstat
WHERE
name = 'redo log replay time';
查询结果可能类似于以下内容：
+-----------------------+------------+
| name | value |
+-----------------------+------------+
| redo log replay time | 123456789 |
+-----------------------+------------+
在上述结果中，value 的值为 123456789，表示 Redo 日志回放总共花费了 123456789 微秒（即约 123 秒）。
value / 1000000
value / 1000
例如：
SELECT
name,
value / 1000000 AS replay_time_in_seconds
FROM
gv$sysstat
WHERE
name = 'redo log replay time';
gv$sysstat 视图中 redo log replay time 的值是以 微秒 为单位的。如果需要更直观的展示，可以通过除以 1000 或 1000000 将其转换为毫秒或秒。
如果有其他问题，请随时提问！
详情请参考:
根据文档库中的信息，针对您的问题可以分两部分进行解答：
gv$sysstat 中 value_type 为 add_value 的累加时间起止定义
在 gv$sysstat 视图中，value_type 为 add_value 的字段表示的是一个累加值。这个累加值是从 OceanBase 数据库实例启动时 开始计算的，直到当前查询时刻为止。也就是说，累加的时间范围是从 数据库实例启动的时间 到 当前查询的时间。
如果您查询 gv$sysstat 中某个 value_type 为 add_value 的统计项（例如 redo log replay time），返回的值是从数据库实例启动以来，所有 Redo 日志回放所花费的总时间。
您可以使用以下 SQL 查询 OceanBase 实例的启动时间：
SELECT startup_time FROM gv$ob_log_stat;
或者：
SELECT value AS startup_time FROM gv$sysstat WHERE name = 'instance_startup_time';
通过对比当前时间和实例启动时间，您可以明确累加值的时间范围。
要查询当前回放的 Redo Log 日志的时间戳，可以通过以下系统视图或监控指标获取相关信息：
__all_virtual_clog_stat 视图__all_virtual_clog_stat 视图记录了 Clog（Commit Log）的相关统计信息，包括日志的生成、落盘和回放状态。
查询示例：
SELECT
tenant_id,
svr_ip,
svr_port,
last_replayed_scn,
last_replayed_timestamp
FROM
__all_virtual_clog_stat;
字段解释：
last_replayed_scn：最后回放的日志 SCN（System Change Number）。last_replayed_timestamp：最后回放的日志时间戳。gv$ob_log_stat 视图gv$ob_log_stat 视图提供了全局范围内的日志统计信息，包括日志的生成、同步和回放情况。
查询示例：
SELECT
tenant_id,
partition_id,
last_replay_log_scn,
last_replay_log_ts
FROM
gv$ob_log_stat;
字段解释：
last_replay_log_scn：最后回放的日志 SCN。last_replay_log_ts：最后回放的日志时间戳。如果您正在使用 OceanBase Cloud Platform (OCP) 或其他监控工具，可以直接通过其内置的监控功能查看 Redo 日志的回放时间戳。OCP 提供了丰富的图表和报表功能，能够直观地展示日志回放的状态。
gv$sysstat 中 value_type 为 add_value 的累加时间起止：
查询当前回放的 Redo Log 日志的时间戳：
__all_virtual_clog_stat 视图中的 last_replayed_timestamp 字段获取。gv$ob_log_stat 视图中的 last_replay_log_ts 字段获取。如果有其他问题，请随时提问！
检索到的文档如下:
根据文档库中的信息，gv$ob_log_stat 视图中的 max_scn 字段并不直接表示 Redo Log 的最大回放时间戳。以下是详细说明：
max_scn 字段的含义
max_scn 字段表示的是当前日志流中已生成的日志的最大 SCN（System Change Number）。SCN 是 OceanBase 数据库中用于标识日志顺序的一个逻辑时间戳，通常与实际时间戳通过函数 SCN_TO_TIMESTAMP() 进行转换。
依据的文档内容：
gv$ob_log_stat 中的 max_scn 字段是一个 SCN 类型，表示当前日志流中已生成日志的最大 SCN 值。查询示例：
SELECT MAX_SCN, SCN_TO_TIMESTAMP(MAX_SCN) AS max_scn_timestamp
FROM gv$ob_log_stat;
字段解释：
MAX_SCN：当前日志流中已生成日志的最大 SCN。SCN_TO_TIMESTAMP(MAX_SCN)：将 SCN 转换为对应的时间戳。如果您需要查询 Redo Log 的最大回放时间戳，应该参考以下字段或视图：
__all_virtual_clog_stat
__all_virtual_clog_stat 视图中的 last_replayed_timestamp 字段表示最后回放的日志时间戳。
查询示例：
SELECT last_replayed_timestamp
FROM __all_virtual_clog_stat;
字段解释：
last_replayed_timestamp：最后回放的日志时间戳。gv$ob_log_stat
虽然 gv$ob_log_stat 的 max_scn 不直接表示回放时间戳，但可以通过 last_replay_log_ts 字段获取最后回放的日志时间戳。
查询示例：
SELECT last_replay_log_ts
FROM gv$ob_log_stat;
字段解释：
last_replay_log_ts：最后回放的日志时间戳。gv$ob_log_stat 的 max_scn 字段表示的是当前日志流中已生成日志的最大 SCN，并不直接表示 Redo Log 的最大回放时间戳。__all_virtual_clog_stat 的 last_replayed_timestamp 或 gv$ob_log_stat 的 last_replay_log_ts 字段。如果有其他问题，请随时提问！
更多信息请查看:
根据您的反馈，如果在当前版本中没有 __all_virtual_clog_stat 表，同时 gv$ob_log_stat 视图也没有 last_replay_log_ts 字段，那么我们需要寻找其他方法来获取 Redo 日志的最大回放时间戳。以下是替代方案的详细说明：
gv$ob_log_stat 的 MAX_SCN 和 SCN_TO_TIMESTAMP 函数虽然 gv$ob_log_stat 没有直接提供回放时间戳的字段，但可以通过以下方式间接获取最大回放时间戳：
MAX_SCN 字段：表示当前日志流中已生成日志的最大 SCN。SCN_TO_TIMESTAMP 函数：可以将 SCN 转换为对应的时间戳。查询示例：
SELECT MAX_SCN, SCN_TO_TIMESTAMP(MAX_SCN) AS max_scn_timestamp
FROM gv$ob_log_stat;
解释：
MAX_SCN 是当前日志流中已生成日志的最大 SCN。SCN_TO_TIMESTAMP(MAX_SCN) 可以将 SCN 转换为时间戳，从而近似表示当前日志的最大生成时间。需要注意的是，MAX_SCN 并不完全等同于回放时间戳，但它可以作为参考值，尤其是在日志同步和回放延迟较小时。
__all_tenant_clog_stat 或类似视图在某些 OceanBase 版本中，可能存在其他系统视图（如 __all_tenant_clog_stat）来记录 Clog 的状态。您可以尝试查询这些视图，查看是否有与日志回放相关的字段。
查询示例：
SELECT tenant_id, svr_ip, svr_port, clog_replay_latency
FROM __all_tenant_clog_stat;
字段解释：
clog_replay_latency：表示日志回放的延迟（单位为毫秒）。如果您正在使用 OceanBase Cloud Platform (OCP) 或其他监控工具，可以直接通过其内置的监控功能查看 Redo 日志的回放时间戳。OCP 提供了丰富的图表和报表功能，能够直观地展示日志回放的状态。
具体步骤：
如果上述方法均不可用，您可以尝试通过业务逻辑手动估算 Redo 日志的最大回放时间戳。具体步骤如下：
write_time）。read_time）。read_time - write_time，得到从写入到查询的延迟。需要注意的是，这种方法仅能估算整体延迟，无法区分日志落盘和回放的具体时间差。
由于当前版本中缺少 __all_virtual_clog_stat 表和 gv$ob_log_stat 的 last_replay_log_ts 字段，您可以尝试以下方法获取 Redo 日志的最大回放时间戳：
gv$ob_log_stat 的 MAX_SCN 和 SCN_TO_TIMESTAMP 函数进行近似估算。__all_tenant_clog_stat 或其他类似视图，查看是否有相关字段。如果有其他问题，请随时提问！
详情请参考: