What may be the consequences of deleting the system keyspace?
I have a Cassandra cluster composed of 2 nodes. One node could not start Cassandra yesterday. I deleted the system keyspace directory and I started the node again. The node is running after system keyspace directory deletion.
What are consequences of system keyspace missing?
All data are present in my cluster and I find no errors at the moment.
clustering nosql cassandra
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
bumped to the homepage by Community♦ 26 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I have a Cassandra cluster composed of 2 nodes. One node could not start Cassandra yesterday. I deleted the system keyspace directory and I started the node again. The node is running after system keyspace directory deletion.
What are consequences of system keyspace missing?
All data are present in my cluster and I find no errors at the moment.
clustering nosql cassandra
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
bumped to the homepage by Community♦ 26 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I have a Cassandra cluster composed of 2 nodes. One node could not start Cassandra yesterday. I deleted the system keyspace directory and I started the node again. The node is running after system keyspace directory deletion.
What are consequences of system keyspace missing?
All data are present in my cluster and I find no errors at the moment.
clustering nosql cassandra
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
I have a Cassandra cluster composed of 2 nodes. One node could not start Cassandra yesterday. I deleted the system keyspace directory and I started the node again. The node is running after system keyspace directory deletion.
What are consequences of system keyspace missing?
All data are present in my cluster and I find no errors at the moment.
clustering nosql cassandra
clustering nosql cassandra
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
edited Aug 17 '16 at 14:34
mustaccio
9,02872136
9,02872136
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
asked Aug 17 '16 at 14:28
afmuloneafmulone
353
353
bumped to the homepage by Community♦ 26 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 26 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The system keyspace is where a Cassandra node maintains information about itself and other nodes. So things like network addresses, responsible token ranges, status from gossip, hints, schema, and other local information. The system keyspace has its own, special replication strategy known as "LocalStrategy:"
cqlsh:system> desc KEYSPACE;
CREATE KEYSPACE system WITH replication = {
'class': 'LocalStrategy'
};
This should tell you that data in the system keyspace isn't replicated to other nodes, and is largely specific to itself.
Sometimes you can fix gossip-related issues by blowing-away the system keyspace (or even just all entries in system.peers). Removing it via the filesystem (as you did) has the same effect. The reason this works, is because it forces the node to rewrite all of that data, most of which it already has (system.local) or it can learn from gossip.
While I wouldn't make a habit out of it, deleting the system keyspace via the filesystem is ok...as long as you have another node in the cluster for it to communicate with.
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f147073%2fwhat-may-be-the-consequences-of-deleting-the-system-keyspace%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The system keyspace is where a Cassandra node maintains information about itself and other nodes. So things like network addresses, responsible token ranges, status from gossip, hints, schema, and other local information. The system keyspace has its own, special replication strategy known as "LocalStrategy:"
cqlsh:system> desc KEYSPACE;
CREATE KEYSPACE system WITH replication = {
'class': 'LocalStrategy'
};
This should tell you that data in the system keyspace isn't replicated to other nodes, and is largely specific to itself.
Sometimes you can fix gossip-related issues by blowing-away the system keyspace (or even just all entries in system.peers). Removing it via the filesystem (as you did) has the same effect. The reason this works, is because it forces the node to rewrite all of that data, most of which it already has (system.local) or it can learn from gossip.
While I wouldn't make a habit out of it, deleting the system keyspace via the filesystem is ok...as long as you have another node in the cluster for it to communicate with.
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
add a comment |
The system keyspace is where a Cassandra node maintains information about itself and other nodes. So things like network addresses, responsible token ranges, status from gossip, hints, schema, and other local information. The system keyspace has its own, special replication strategy known as "LocalStrategy:"
cqlsh:system> desc KEYSPACE;
CREATE KEYSPACE system WITH replication = {
'class': 'LocalStrategy'
};
This should tell you that data in the system keyspace isn't replicated to other nodes, and is largely specific to itself.
Sometimes you can fix gossip-related issues by blowing-away the system keyspace (or even just all entries in system.peers). Removing it via the filesystem (as you did) has the same effect. The reason this works, is because it forces the node to rewrite all of that data, most of which it already has (system.local) or it can learn from gossip.
While I wouldn't make a habit out of it, deleting the system keyspace via the filesystem is ok...as long as you have another node in the cluster for it to communicate with.
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
add a comment |
The system keyspace is where a Cassandra node maintains information about itself and other nodes. So things like network addresses, responsible token ranges, status from gossip, hints, schema, and other local information. The system keyspace has its own, special replication strategy known as "LocalStrategy:"
cqlsh:system> desc KEYSPACE;
CREATE KEYSPACE system WITH replication = {
'class': 'LocalStrategy'
};
This should tell you that data in the system keyspace isn't replicated to other nodes, and is largely specific to itself.
Sometimes you can fix gossip-related issues by blowing-away the system keyspace (or even just all entries in system.peers). Removing it via the filesystem (as you did) has the same effect. The reason this works, is because it forces the node to rewrite all of that data, most of which it already has (system.local) or it can learn from gossip.
While I wouldn't make a habit out of it, deleting the system keyspace via the filesystem is ok...as long as you have another node in the cluster for it to communicate with.
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
The system keyspace is where a Cassandra node maintains information about itself and other nodes. So things like network addresses, responsible token ranges, status from gossip, hints, schema, and other local information. The system keyspace has its own, special replication strategy known as "LocalStrategy:"
cqlsh:system> desc KEYSPACE;
CREATE KEYSPACE system WITH replication = {
'class': 'LocalStrategy'
};
This should tell you that data in the system keyspace isn't replicated to other nodes, and is largely specific to itself.
Sometimes you can fix gossip-related issues by blowing-away the system keyspace (or even just all entries in system.peers). Removing it via the filesystem (as you did) has the same effect. The reason this works, is because it forces the node to rewrite all of that data, most of which it already has (system.local) or it can learn from gossip.
While I wouldn't make a habit out of it, deleting the system keyspace via the filesystem is ok...as long as you have another node in the cluster for it to communicate with.
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
answered Oct 4 '16 at 15:04
AaronAaron
2,59211227
2,59211227
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f147073%2fwhat-may-be-the-consequences-of-deleting-the-system-keyspace%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
