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

feat: Use version to synchronize catalog #749

Merged
merged 4 commits into from
Mar 10, 2022

Conversation

HuaHuaY
Copy link
Contributor

@HuaHuaY HuaHuaY commented Mar 8, 2022

What's changed and what's your intention?

Use version to synchronize catalog.

There is a version in return value of Create and Drop RPC. Meta will send a notification with a bigger version. create/drop in CatalogConnector will wait until the value in message from ObserverManager is bigger than the return value of Create and Drop RPC.

Checklist

  • I have written necessary docs and comments
  • I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)

related #567 #361

@codecov
Copy link

codecov bot commented Mar 8, 2022

Codecov Report

Merging #749 (11ef557) into main (4e9e18b) will decrease coverage by 0.00%.
The diff coverage is 81.98%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main     #749      +/-   ##
============================================
- Coverage     72.42%   72.42%   -0.01%     
  Complexity     2762     2762              
============================================
  Files           918      918              
  Lines         53289    53304      +15     
  Branches       1787     1787              
============================================
+ Hits          38594    38604      +10     
- Misses        13801    13806       +5     
  Partials        894      894              
Flag Coverage Δ
java 61.17% <ø> (ø)
rust 77.14% <81.98%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
rust/common/src/catalog/mod.rs 66.66% <ø> (ø)
rust/meta/src/hummock/model/current_version_id.rs 100.00% <ø> (ø)
rust/meta/src/manager/notification.rs 83.33% <ø> (ø)
rust/meta/src/rpc/service/catalog_service.rs 100.00% <ø> (ø)
rust/meta/src/manager/catalog.rs 75.54% <73.33%> (-0.09%) ⬇️
rust/frontend/src/observer/observer_manager.rs 86.66% <75.00%> (+1.48%) ⬆️
rust/meta/src/model/catalog.rs 91.22% <86.66%> (-1.63%) ⬇️
rust/frontend/src/catalog/catalog_service.rs 86.22% <86.95%> (-0.60%) ⬇️
rust/frontend/src/scheduler/schedule.rs 89.84% <100.00%> (ø)
rust/frontend/src/session.rs 98.46% <100.00%> (ø)
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4e9e18b...11ef557. Read the comment docs.

@yezizp2012 yezizp2012 requested a review from BugenZhao March 8, 2022 07:33
Copy link
Member

@BugenZhao BugenZhao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM.

Comment on lines 218 to 221
while *rx.borrow() < version {
rx.changed()
.await
.map_err(|e| RwError::from(InternalError(e.to_string())))?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may extract this to a separated function like wait_version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. The frontend should keep a max committed version in memory and could be initialized when start and fetch from meta. So the meta should stores a global catalog max committed version. This will be helpful for catalog MVCC implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Add a struct CatalogVersionGenerator in CatalogManagerCore of meta.

@@ -150,7 +160,7 @@ where
table.insert(&*self.meta_store_ref).await?;
core.add_table(table.clone());

if let TableInfo::MaterializedView(mview_info) = table.get_info().unwrap() {
if let TableInfo::MaterializedView(mview_info) = table.get_info()? {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The info must exist and we should unwrap here.

Copy link
Member

@yezizp2012 yezizp2012 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM

@BowenXiao1999
Copy link
Contributor

So this PR is saying: Update local catalog cache iff the version from meta is larger than local?

@HuaHuaY
Copy link
Contributor Author

HuaHuaY commented Mar 9, 2022

So this PR is saying: Update local catalog cache iff the version from meta is larger than local?

Yes. When CatalogConnector calls create/drop, it will get a new catalog version, suppose "A". create/drop will wait until the version in notification is bigger than "A" or equal to "A". So when create/drop returns, we make sure catalog has been updated.

Copy link
Contributor

@BowenXiao1999 BowenXiao1999 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least better than check database by name.

Not dive into detail. LGTM.

.get_schema(db_name, schema_name)
.is_none()
{
while *rx.borrow() < version {
rx.changed()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that the version gets changed between *rx.borrow() < version and rx.changed(), and the program gets stuck?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems no problem. My fault.

@@ -90,7 +90,7 @@ impl NotificationManager {
}))
.await
.into_iter()
.collect::<RwResult<()>>()
.collect::<Result<()>>()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try_collect?

.get_database(db_name)
.is_some()
{
while *rx.borrow() < version {
Copy link
Contributor

@skyzh skyzh Mar 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that we are using this in a wrong way...

This method does not mark the returned value as seen, so future calls to changed may return immediately even if you have already seen the value with a call to borrow.

should call borrow_and_update instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise .changed will always return immediately, and we are spinning on this thread.

Copy link
Contributor

@skyzh skyzh Mar 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the version is not latest, the current approach may cause the condition being checked twice. e.g., rx.borrow() returns 1, but as we didn't call changed, the following changed will immediately return, and we will get rx.borrow() == 1 again. But this time, 1 is marked seen, so there won't be problem, and we will wait for the next update.

I'd recommend using borrow_and_update for this scenario, but there won't be problem if we don't modify this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the version is not latest, the current approach may cause the condition being checked twice. e.g., rx.borrow() returns 1, but as we didn't call changed, the following changed will immediately return, and we will get rx.borrow() == 1 again. But this time, 1 is marked seen, so there won't be problem.

I'd recommend using borrow_and_update for this scenario, but there won't be problem if we don't modify this.

Yes, you are right. I will change it.

@HuaHuaY HuaHuaY merged commit fefb7a2 into main Mar 10, 2022
@HuaHuaY HuaHuaY deleted the zehua/catalog_waiting_mechanism branch March 10, 2022 05:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants