DCF模式，在主节点上执行写操作时，若Req消息丢失或延迟，客户端会阻塞，手动终止之后操作仅在本地生效

【标题描述】:
DCF模式，在主节点上执行写操作时，若Req消息丢失或延迟，主节点会一直阻塞等待从节点的Ack消息，没有超时机制。
当手动（Ctrl-C）停止写操作时，写操作会在本地生效，导致系统不一致。此后主节点无法再写入，因为状态不一致。故整个系统已不可写。
【测试类型：SQL功能/存储功能/接口功能/工具功能/性能/并发/压力长稳/故障注入/安全/资料/编码规范】【测试版本：x.x.x】 问题描述

【操作系统和硬件信息】(查询命令: cat /etc/system-release, uname -a):
openEuler release 22.03 LTS
Linux 3adf3c2c795d 4.15.0-194-generic #205-Ubuntu SMP Fri Sep 16 19:49:27 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
【测试环境】(单机/1主x备x级联备):
1主2备
【被测功能】:

【测试类型】:

【数据库版本】(查询命令: gaussdb -V):
gaussdb (openGauss 5.0.0 build ) compiled at 2023-04-06 15:35:14 commit 0 last mr debug
【预置条件】:

【操作步骤】(请填写详细的操作步骤):
插桩DCF源码rep_leader.c的rep_appendlog_node函数，使其提前返回或插入延迟函数，模拟消息丢失或延迟。
static status_t rep_appendlog_node(uint32 stream_id, uint32 node_id, dcf_role_t default_role, uint64 last_log_index,
    bool8* node_exists_log)
{
    uint64 old_next_index = (uint64)cm_atomic_get((atomic_t*)&NEXT_INDEX);
    uint64 log_begin = old_next_index == CM_INVALID_INDEX_ID ? 1 : old_next_index;
    log_begin = MAX(log_begin, stg_first_index(stream_id));
    uint64 log_count = rep_calu_log_count(stream_id, node_id, default_role, log_begin, last_log_index);
    *node_exists_log = (log_count > 0);

/* Logs are sent even if log_count==0.
    Periodically sending empty logs ensures that lost packets are retransmitted */
    mec_message_t pack;
    CM_RETURN_IFERR(mec_alloc_pack(&pack, MEC_CMD_APPEND_LOG_RPC_REQ, g_cur_node_id, node_id, stream_id));
    uint64 pre_log_index = log_begin == CM_INVALID_INDEX_ID ? CM_INVALID_INDEX_ID : log_begin - 1;
    rep_apendlog_req_t appendlog_req;
    rep_init_appendlog_head(stream_id, &appendlog_req, pre_log_index, last_log_index);
    CM_RETURN_IFERR_EX(rep_encode_appendlog_head(&pack, &appendlog_req), mec_release_pack(&pack));
    uint32 log_count_pos = mec_get_write_pos(&pack) - sizeof(uint64);

uint64 j = 0;
    uint32 total_size = 0;
    for (uint64 index = log_begin; j < log_count; index++, j++) {
        log_entry_t* entry = stg_get_entry(stream_id, index);
        if (entry == NULL) {
            break;
        }
        total_size += (sizeof(rep_log_t) + ENTRY_SIZE(entry));
        if (total_size > MESSAGE_BUFFER_SIZE && j > 0) {
            LOG_DEBUG_INF("[REP]total_size[%u] is enough, send size[%u]. log_count[%llu], j[%llu]",
                total_size, (uint32)(total_size - (sizeof(rep_log_t) + ENTRY_SIZE(entry))), log_count, j);
            stg_entry_dec_ref(entry);
            break;
        }
        status_t ret = rep_encode_one_log(&pack, log_count_pos, j + 1, entry);
        stg_entry_dec_ref(entry);
        if (ret != CM_SUCCESS) {
            mec_release_pack(&pack);
            LOG_DEBUG_ERR("[REP]encode_one_log fail, index=%llu, j=%llu", index, j);
            return CM_ERROR;
        }
        ps_record1(PS_PACK, index);
    }
    appendlog_req.log_count = j;
    // 在此提前返回或插入延迟函数
【预期输出】:
主节点的写操作超时后返回错误，系统仍保持一致。
【实际输出】:
主节点一直阻塞等待系统达成一致，没有超时机制。手动停止写操作之后，写操作在主节点本地生效，导致系统不一致。
【原因分析】:
1. 这个问题的根因
DCF同步没有超时机制
2. 问题推断过程
3. 还有哪些原因可能造成类似现象
4. 该问题是否有临时规避措施
5. 问题解决方案
6. 预计修复问题时间

【日志信息】(请附上日志文件、截图、coredump信息):
![输入图片说明](https://foruda.gitee.com/images/1700490020054139278/c9a2342b_8043008.png "屏幕截图")
【测试代码】:

openGauss/openGauss-server

内容风险标识

评论 (5)

openGauss/openGauss-server .gitee-modal { width: 500px !important; }

内容风险标识