Add close method for Region trait

[v0y4g3r]

What type of enhancement is this?

API improvement

What does the enhancement do?

A close method should be added to Region trait so that the resources held by Region can be gracefully release, for example, when a table is dropped.

Implementation challenges

In order to gracefully close a region, we need to implement following tasks:

• flag the region as "closed" to prevent future writes feat: add close method for the region trait #970;
  • In distributed mode, region state should be maintained in metasrv and regions should be agnostic to state implementations. But we can start from maintaing the state in datanode's memory;
• regions spawn background tasks to handle table flush or compaction etc, these tasks need to be cancelled feat: add close method for the region trait #970.
  • Flush task handle
    

    greptimedb/src/storage/src/region/writer.rs

    Line 513 in 8ffc078

    async fn trigger_flush<S: LogStore>(&mut self, ctx: &WriterContext<'_, S>) -> Result<()> {

  • Compaction task handle is not present until Support table compaction #930 is resolved.

[evenyag]

We could acquire the write lock of the region (so we can ensure all pending writes before close are done) and mark the region as closing

[WenyXu]

Cool, can I take this

[WenyXu]

I'm currently work on the part that shut down the server gracefully when it received the ctrl-c signal (and I guess we also need to handle the SIGTERM), But I encountered some issues. The Command didn't return a server instance, so I need to design a pattern to notify the instance held by Command.

greptimedb/src/cmd/src/bin/greptime.rs

Lines 33 to 37 in 8ffc078

	impl Command {
	async fn run(self) -> Result<()> {
	self.subcmd.run().await
	}
	}

The first pattern that came to my mind is to use a channel and pass the channel as a part of ctx into Command's run method. It will look like the following:

  let (rx, tx) = channel();

    let ctx = Context { sigterm: tx };

    tokio::select! {
        result = cmd.run(ctx) => {
            if let Err(err) = result {
                error!(err; "Fatal error occurs!");
            }
        }
        _ = tokio::signal::ctrl_c() => {
            info!("Goodbye!");
            rx.send(());
        }
    }

Then we can handle the signal in the StartCommand's run method.

greptimedb/src/cmd/src/datanode.rs

Lines 68 to 83 in 8ffc078

	impl StartCommand {
	async fn run(self) -> Result<()> {
	logging::info!("Datanode start command: {:#?}", self);
	let opts: DatanodeOptions = self.try_into()?;
	logging::info!("Datanode options: {:#?}", opts);
	Datanode::new(opts)
	.await
	.context(StartDatanodeSnafu)?
	.start()
	.await
	.context(StartDatanodeSnafu)
	}
	}

Is this a good solution? Any suggestions are welcomed.

[evenyag]

Could we add another enum, like Application to wrap structs like Datanode, Frontend?

enum Application {
    Datanode(Datanode),
    Frontend(Frontend),
}

We build the application from the command and run that application.

let app = cmd.build();
tokio::select! {
    result = app.run(ctx) => {},
    _ = tokio::signal::ctrl_c() => {
        app.stop();
    }
}

[evenyag]

@v0y4g3r Maybe we could change this into a tracking issue to graceful shutdown