guyinyou opened a new issue, #6497: URL: https://github.com/apache/rocketmq/issues/6497
The issue tracker is used for bug reporting purposes **ONLY** whereas feature request needs to follow the [RIP process](https://github.com/apache/rocketmq/wiki/RocketMQ-Improvement-Proposal). To avoid unnecessary duplication, please check whether there is a previous issue before filing a new one. It is recommended to start a discussion thread in the [mailing lists](http://rocketmq.apache.org/about/contact/) or [github discussions](https://github.com/apache/rocketmq/discussions) in cases of discussing your deployment plan, API clarification, and other non-bug-reporting issues. We welcome any friendly suggestions, bug fixes, collaboration, and other improvements. Please ensure that your bug report is clear and self-contained. Otherwise, it would take additional rounds of communication, thus more time, to understand the problem itself. Generally, fixing an issue goes through the following steps: 1. Understand the issue reported; 1. Reproduce the unexpected behavior locally; 1. Perform root cause analysis to identify the underlying problem; 1. Create test cases to cover the identified problem; 1. Work out a solution to rectify the behavior and make the newly created test cases pass; 1. Make a pull request and go through peer review; As a result, it would be very helpful yet challenging if you could provide an isolated project reproducing your reported issue. Anyway, please ensure your issue report is informative enough for the community to pick up. At a minimum, include the following hints: **BUG REPORT** 1. Please describe the issue you observed: - What did you do (The steps to reproduce)? - What is expected to see? - What did you see instead? 2. Please tell us about your environment: 3. Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc): At present, there is only the flushCQ mechanism, which will cause the compactionTopic data to be lost and cannot be recovered during downtime. a. You should make full use of the "graceful shutdown" judgment and recovery capabilities, and just flash the full amount of CQ and Log before shutdown. b. In order to reduce the amount of data that needs to be flushed in before shutdown, the compactionLog is included in the daily flushing of the commitlog. c. Since the recovery capability of "Graceful Shutdown" is aimed directly at the last 3 commitlog files, other data (replacing when the standby machine is rebuilt), because it cannot be recovered, it is necessary to strictly ensure that the disk is swiped, for example, before the moveFile operation of replacing Brush plate. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
