-
Notifications
You must be signed in to change notification settings - Fork 328
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: adds information_schema cluster_info table #3832
Conversation
4855bf5
to
2c909a5
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3832 +/- ##
==========================================
- Coverage 85.70% 85.29% -0.42%
==========================================
Files 954 955 +1
Lines 162947 163262 +315
==========================================
- Hits 139656 139250 -406
- Misses 23291 24012 +721 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no peer-id
concept in frontend (and metasrv maybe). Introducing unique id will bring in overall operation and tooling complexity, which we would like to avoid. We can keep it all 0
and it requires explanations from docs.
Another idea is to change peer_addr
to hostname
:
- The port number in peer_addr is implemented as grpc service port. However. it makes little sense when we listing those grpc ports from frontend/datanode/metasrv together because they serve different purpose.
- In kubernetes and some other modern environment, hostname offers better readability than IP addresses. Also IP address may change after pod rebuild.
And I wonder if we have sufficient information to include a new field like state
or health
.
|
746e951
to
876bcee
Compare
Metasrv cannot have a |
@fengjiachun @sunng87 @MichaelScofield Please take a look, thank you. |
I added an cc @sunng87 |
Co-authored-by: Jeremyhi <jiachun_feng@proton.me>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
#2931
Close #1768 and close #3141
What's changed and what's your intention?
First, rename the
greptime_region_peers
toregion_peers
. It is more appropriate.Second, adds
cluster_info
table toinformation_schema
, it provides the information about the current topology of the cluster.It depends on GreptimeTeam/greptime-proto#160
peer_id
: the peer server id.peer_type
: the peer type, such asdatanode
,frontend
,metasrv
etc.peer_addr
: the peer gRPC address.version
: the build package version of the peer.git_commit
: the build git commit hash of the peer.start_time
: the starting time of the peer.uptime
: the uptime of the peer.active_time
: the time since the last activity of the peer.For example
In standalone mode:
In standalone mode, the
peer_addr
is always empty andpeer_id
is always0
.In distributed mode:
It will list all the nodes' info in cluster. The
peer_id
in frontends are always-1
.Checklist