Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Housekeeping structure improvement #706

Closed
fourjae opened this issue Dec 3, 2023 · 4 comments · Fixed by #932
Closed

Housekeeping structure improvement #706

fourjae opened this issue Dec 3, 2023 · 4 comments · Fixed by #932
Assignees
Labels
enhancement 🌟 New feature or request

Comments

@fourjae
Copy link
Contributor

fourjae commented Dec 3, 2023

What would you like to be added:

Cluster mode, and several background tasks are required, so the Housekeeping execution structure for this needs to be improved.

func (h *Housekeeping) run() {

Why is this needed:

Currently, Housekeeping is running a background routine unrelated to RPC and is running at regular intervals.

  • the housekeeping task only has logic to remove inactive clients. However, other logic may be added later. How should we introduce a structure for this?

    • In addition to Yorkie, it would be a good idea to find a way to run batch or background routines on other servers and apply them to Yorkie.

  • In yorkie's cluster mode, I think problems will arise if multiple nodes run the same housekeeping logic redundantly at the same time.

    • Master nodes are elected through voting, To prevent two nodes from being elected as master It works by acquiring a lock in MongoDB, There may be a way to have only the master node run afterwards

    • Kubernetes uses Jobs to execute necessary housekeeping tasks.

    • If in standalone mode, There may be a way to set up a cron job or detect a specific event and run a script.

I think we need to research good practices, pros and cons, and come up with a method that suits the yorkie project.

@fourjae fourjae added the enhancement 🌟 New feature or request label Dec 3, 2023
@krapie
Copy link
Member

krapie commented Dec 4, 2023

Master nodes are elected through voting, To prevent two nodes from being elected as master It works by acquiring a lock in MongoDB, There may be a way to have only the master node run afterwards

For leader-election based master-slave structure, I have implemented leader election using MongoDB: #529

Kubernetes uses Jobs to execute necessary housekeeping tasks.

I think we can use CronJob to regularly run housekeeping process or use simple Job to run housekeeping on demand (this will require API for triggering). For implementation, we can use yorkie CLI like yorkie housekeeping start to only activate housekeeping mechanism from the yorkie server.

If in standalone mode, There may be a way to set up a cron job or detect a specific event and run a script.

For standalone mode, both cron job or event-based job will be well suited for several background tasks to run. For implementation, https://github.com/go-co-op/gocron will do the work for cron job.

@fourjae
Copy link
Contributor Author

fourjae commented Dec 4, 2023

I read #529 and understood the comments and source code changes. Very interesting!

But I still have some questions.

  1. If you are currently only doing housekeeping work, I think it would be better to have only the master node perform housekeeping work on that node through leader election rather than a CronJob. What are the benefits of using CronJob?

  2. I think additional improvements are needed not only at the infrastructure but also at the code level.
    Looking at the housekeeping loop code of the current run() function, only the deactivateCandidates task is performed at certain intervals. If other tasks are added here, both must be done at the same time.
    If another task is added and this task has to run separately from deactivateCandidates, how would I improve the code? Should I create different run() functions?

@krapie
Copy link
Member

krapie commented Dec 4, 2023

If you are currently only doing housekeeping work, I think it would be better to have only the master node perform housekeeping work on that node through leader election rather than a CronJob. What are the benefits of using CronJob?

I think we can remove the housekeeping & leader election overhead of each servers on the cluster, which will ease server to handle more workloads.

If we run housekeeping only on the master node, it will be a huge burden for the master node to process as cluster gets bigger (elected nodes might die out because of the overhead, which will lead something like election storm).

I think additional improvements are needed not only at the infrastructure but also at the code level.
Looking at the housekeeping loop code of the current run() function, only the deactivateCandidates task is performed at certain intervals. If other tasks are added here, both must be done at the same time.
If another task is added and this task has to run separately from deactivateCandidates, how would I improve the code? Should I create different run() functions?

I agree that we should improve current housekeeping structure. One simple idea is to reference server/backend/background.go and use this to create several background goroutines.

Another idea is that we can implement something like DAG workflow to schedule and run background process that has dependency. I found something similar to this idea: https://github.com/fieldryand/goflow

@hackerwins
Copy link
Member

hackerwins commented Jul 19, 2024

For standalone mode, both cron job or event-based job will be well suited for several background tasks to run. For implementation, https://github.com/go-co-op/gocron will do the work for cron job.

I'd like to evaluate the possibility of introducing gocron library for this issue. This library provides a simple way to schedule tasks in Go. And it seems that the library also considering both standalone and distributed system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 🌟 New feature or request
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants