Re: nodetool repair and compact

[James Shaw]

you may use:  nodetool upgradesstables -a keyspace_name table_name
it will re-write this table's sstable files to current version, while
re-writing, will evit droppable tombstones (expired +  gc_grace_seconds
(default 10 days) ), if partition cross different files, they will still be
kept, but most droppable tombstones gone and size reduced.
It works well for ours.



On Mon, Apr 2, 2018 at 12:45 AM, Jon Haddad  wrote:

> You’ll find the answers to your questions (and quite a bit more) in this
> blog post from my coworker: http://thelastpickle.com/blog/2016/
> 07/27/about-deletes-and-tombstones.html
>
> Repair doesn’t clean up tombstones, they’re only removed through
> compaction.  I advise taking care with nodetool compact, most of the time
> it’s not a great idea for a variety of reasons.  Check out the above post,
> if you still have questions, ask away.
>
>
> On Apr 1, 2018, at 9:41 PM, Xiangfei Ni  wrote:
>
> Hi All,
>   I want to delete the expired tombstone, someone uses nodetool repair
> ,but someone uses compact,so I want to know which one is the correct way,
>   I have read the below pages from Datastax,but the page just tells us how
> to use the command,but doesn’t tell us what it is exactly dose,
>   https://docs.datastax.com/en/cassandra/3.0/cassandra/
> tools/toolsRepair.html
>could anybody tell me how to clean the tombstone and give me some
> materials include the detailed instruction about the nodetool command and
> options?Web link is also ok.
>   Thanks very much
> Best Regards,
>
> 倪项菲*/ **David Ni*
> 中移德电网络科技有限公司
>
> Virtue Intelligent Network Ltd, co.
> Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
> Mob: +86 13797007811 <+86%20137%209700%207811>|Tel: + 86 27 5024 2516
> <+86%2027%205024%202516>
>
>
>

Re: nodetool repair and compact

[Alain RODRIGUEZ]

Hi,

it will re-write this table's sstable files to current version, while
> re-writing, will evit droppable tombstones (expired +  gc_grace_seconds
> (default 10 days) ), if partition cross different files, they will still
> be kept, but most droppable tombstones gone and size reduced.
>

Nice tip James, I never thought about doing this, it could have been handy
:).

Now, these compactions can be automatically done using the proper tombstone
compaction settings in most cases. Generally, tombstone compaction is
enabled, but if tombstone eviction is still an issue, you might want to
give a try enabling 'unchecked_tombstone_compaction' in the table options.
This might claim quite a lot of disk space (depending on the sstable
overlapping levels).

In case manual action is really needed (even more if it is run
automatically), I would recommend using 'User Defined Compactions' - UDC
(accessible through JMX at least) instead of 'uprade sstable':

- It will remove the tombstones the same way, but with no side effect if
you are currently upgrading for example. If  'upgradesstable' is run as a
routine operation, you might forget about it and suffer consequences.
'upgradesstable' is not only doing the compaction.
- With UDC, you can trigger the compaction of the sstables you want to
remove the tombstones from, instead of compacting *all* the sstables for a
given table.

This last point can prevent harming the cluster with useless compaction,
and even allow the operator to do things like: 'Compact the 10% biggest
sstables, that have an estimated tombstone ratio above 0.5, every day' or
'compact any sstable having more than 75% of tombstones' as you see fit,
and using information such as the sstables sizes and sstablemetadata to get
the tombstone ratio.

C*heers,
---
Alain Rodriguez - @arodream - al...@thelastpickle.com
France / Spain

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

2018-04-02 14:55 GMT+01:00 James Shaw :

> you may use:  nodetool upgradesstables -a keyspace_name table_name
> it will re-write this table's sstable files to current version, while
> re-writing, will evit droppable tombstones (expired +  gc_grace_seconds
> (default 10 days) ), if partition cross different files, they will still
> be kept, but most droppable tombstones gone and size reduced.
> It works well for ours.
>
>
>
> On Mon, Apr 2, 2018 at 12:45 AM, Jon Haddad  wrote:
>
>> You’ll find the answers to your questions (and quite a bit more) in this
>> blog post from my coworker: http://thelastpickle
>> .com/blog/2016/07/27/about-deletes-and-tombstones.html
>>
>> Repair doesn’t clean up tombstones, they’re only removed through
>> compaction.  I advise taking care with nodetool compact, most of the time
>> it’s not a great idea for a variety of reasons.  Check out the above post,
>> if you still have questions, ask away.
>>
>>
>> On Apr 1, 2018, at 9:41 PM, Xiangfei Ni  wrote:
>>
>> Hi All,
>>   I want to delete the expired tombstone, someone uses nodetool repair
>> ,but someone uses compact,so I want to know which one is the correct way,
>>   I have read the below pages from Datastax,but the page just tells us
>> how to use the command,but doesn’t tell us what it is exactly dose,
>>   https://docs.datastax.com/en/cassandra/3.0/cassandra/tools
>> /toolsRepair.html
>>could anybody tell me how to clean the tombstone and give me some
>> materials include the detailed instruction about the nodetool command and
>> options?Web link is also ok.
>>   Thanks very much
>> Best Regards,
>>
>> 倪项菲*/ **David Ni*
>> 中移德电网络科技有限公司
>>
>> Virtue Intelligent Network Ltd, co.
>> Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
>> Mob: +86 13797007811 <+86%20137%209700%207811>|Tel: + 86 27 5024 2516
>> <+86%2027%205024%202516>
>>
>>
>>
>

Re: nodetool repair and compact

[Alain RODRIGUEZ]

I have just this been told that my first statement is inaccurate:

If  'upgradesstable' is run as a routine operation, you might forget about
> it and suffer consequences. 'upgradesstable' is not only doing the
> compaction.


I should probably have checked upgradesstable closely before making this
statement and I definitely will.

Yet, I believe the second point still holds though: 'With UDC, you can
trigger the compaction of the sstables you want to remove the tombstones
from, instead of compacting *all* the sstables for a given table.'

C*heers,

2018-04-02 16:39 GMT+01:00 Alain RODRIGUEZ :

> Hi,
>
> it will re-write this table's sstable files to current version, while
>> re-writing, will evit droppable tombstones (expired +  gc_grace_seconds
>> (default 10 days) ), if partition cross different files, they will still
>> be kept, but most droppable tombstones gone and size reduced.
>>
>
> Nice tip James, I never thought about doing this, it could have been handy
> :).
>
> Now, these compactions can be automatically done using the proper
> tombstone compaction settings in most cases. Generally, tombstone
> compaction is enabled, but if tombstone eviction is still an issue, you
> might want to give a try enabling 'unchecked_tombstone_compaction' in the
> table options. This might claim quite a lot of disk space (depending on the
> sstable overlapping levels).
>
> In case manual action is really needed (even more if it is run
> automatically), I would recommend using 'User Defined Compactions' - UDC
> (accessible through JMX at least) instead of 'uprade sstable':
>
> - It will remove the tombstones the same way, but with no side effect if
> you are currently upgrading for example. If  'upgradesstable' is run as a
> routine operation, you might forget about it and suffer consequences.
> 'upgradesstable' is not only doing the compaction.
> - With UDC, you can trigger the compaction of the sstables you want to
> remove the tombstones from, instead of compacting *all* the sstables for a
> given table.
>
> This last point can prevent harming the cluster with useless compaction,
> and even allow the operator to do things like: 'Compact the 10% biggest
> sstables, that have an estimated tombstone ratio above 0.5, every day' or
> 'compact any sstable having more than 75% of tombstones' as you see fit,
> and using information such as the sstables sizes and sstablemetadata to get
> the tombstone ratio.
>
> C*heers,
> ---
> Alain Rodriguez - @arodream - al...@thelastpickle.com
> France / Spain
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> 2018-04-02 14:55 GMT+01:00 James Shaw :
>
>> you may use:  nodetool upgradesstables -a keyspace_name table_name
>> it will re-write this table's sstable files to current version, while
>> re-writing, will evit droppable tombstones (expired +  gc_grace_seconds
>> (default 10 days) ), if partition cross different files, they will still
>> be kept, but most droppable tombstones gone and size reduced.
>> It works well for ours.
>>
>>
>>
>> On Mon, Apr 2, 2018 at 12:45 AM, Jon Haddad  wrote:
>>
>>> You’ll find the answers to your questions (and quite a bit more) in this
>>> blog post from my coworker: http://thelastpickle
>>> .com/blog/2016/07/27/about-deletes-and-tombstones.html
>>>
>>> Repair doesn’t clean up tombstones, they’re only removed through
>>> compaction.  I advise taking care with nodetool compact, most of the time
>>> it’s not a great idea for a variety of reasons.  Check out the above post,
>>> if you still have questions, ask away.
>>>
>>>
>>> On Apr 1, 2018, at 9:41 PM, Xiangfei Ni  wrote:
>>>
>>> Hi All,
>>>   I want to delete the expired tombstone, someone uses nodetool repair
>>> ,but someone uses compact,so I want to know which one is the correct way,
>>>   I have read the below pages from Datastax,but the page just tells us
>>> how to use the command,but doesn’t tell us what it is exactly dose,
>>>   https://docs.datastax.com/en/cassandra/3.0/cassandra/tools
>>> /toolsRepair.html
>>>could anybody tell me how to clean the tombstone and give me some
>>> materials include the detailed instruction about the nodetool command and
>>> options?Web link is also ok.
>>>   Thanks very much
>>> Best Regards,
>>>
>>> 倪项菲*/ **David Ni*
>>> 中移德电网络科技有限公司
>>>
>>> Virtue Intelligent Network Ltd, co.
>>> Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
>>> Mob: +86 13797007811 <+86%20137%209700%207811>|Tel: + 86 27 5024 2516
>>> <+86%2027%205024%202516>
>>>
>>>
>>>
>>
>

Large Partitions

[shalom sagges]

Hi All,

I ran nodetool cfstats (v2.0.14) on a keyspace and found that there are a
few large partitions. I assume that since "Compacted partition maximum
bytes": 802187438 (~800 MB) and since
"Compacted partition mean bytes": 100465 (~100 KB), it means that most
partitions are in okay size and only a few are large. Am I assuming
correctly?

If so, can anyone suggest how to find those large partitions and how to
deal with them? (cfstats output below)

Thanks!


nodetool cfstats keyspace1;

Table: table1
SSTable count: 16
Space used (live), bytes: 453844035587
Space used (total), bytes: 453844035587
Off heap memory used (total), bytes: 440787635
SSTable Compression Ratio: 0.17417149031966575
Number of keys (estimate): 33651200
Memtable cell count: 27966
Memtable data size, bytes: 41698140
Memtable switch count: 199727
Local read count: 86494530
Local read latency: 2.646 ms
Local write count: 247712138
Local write latency: 0.030 ms
Pending tasks: 0
Bloom filter false positives: 2182242
Bloom filter false ratio: 0.02251
Bloom filter space used, bytes: 53135136
Bloom filter off heap memory used, bytes: 53135008
Index summary off heap memory used, bytes: 11560419
Compression metadata off heap memory used, bytes: 376092208
Compacted partition minimum bytes: 373

*Compacted partition maximum bytes: 802187438Compacted partition mean
bytes: 100465*
Average live cells per slice (last five minutes): 37.0
Average tombstones per slice (last five minutes): 0.0

Re: Large Partitions

[Ali Hubail]

system.log should show you some warnings about wide rows. Do a grep on 
system.log for 'Writing large partition' The message could be different 
for the c* version you're using though. Plus, this doesn't show you all of 
the large partitions.

There is a nice tool that analyzes sstables and can show the large 
partitions:
https://github.com/tolbertam/sstable-tools


By "how to deal with them?" it depends. If you don't need those partitions 
then you can delete them. You can also use TTL if it fits you or remodel 
your table to only hold upto 100k rows or 100mb per partition (whichever 
comes first). If you're going to remodel the table, aim for much less than 
100k/100mb per partition.

Ali Hubail

Confidentiality warning: This message and any attachments are intended 
only for the persons to whom this message is addressed, are confidential, 
and may be privileged. If you are not the intended recipient, you are 
hereby notified that any review, retransmission, conversion to hard copy, 
copying, modification, circulation or other use of this message and any 
attachments is strictly prohibited. If you receive this message in error, 
please notify the sender immediately by return email, and delete this 
message and any attachments from your system. Petrolink International 
Limited its subsidiaries, holding companies and affiliates disclaims all 
responsibility from and accepts no liability whatsoever for the 
consequences of any unauthorized person acting, or refraining from acting, 
on any information contained in this message. For security purposes, staff 
training, to assist in resolving complaints and to improve our customer 
service, email communications may be monitored and telephone calls may be 
recorded.



shalom sagges  
04/02/2018 03:57 PM
Please respond to
user@cassandra.apache.org


To
user@cassandra.apache.org, 
cc

Subject
Large Partitions






Hi All, 

I ran nodetool cfstats (v2.0.14) on a keyspace and found that there are a 
few large partitions. I assume that since "Compacted partition maximum 
bytes": 802187438 (~800 MB) and since 
"Compacted partition mean bytes": 100465 (~100 KB), it means that most 
partitions are in okay size and only a few are large. Am I assuming 
correctly?

If so, can anyone suggest how to find those large partitions and how to 
deal with them? (cfstats output below)

Thanks! 


nodetool cfstats keyspace1;

Table: table1
SSTable count: 16
Space used (live), bytes: 453844035587
Space used (total), bytes: 453844035587
Off heap memory used (total), bytes: 440787635
SSTable Compression Ratio: 0.17417149031966575
Number of keys (estimate): 33651200
Memtable cell count: 27966
Memtable data size, bytes: 41698140
Memtable switch count: 199727
Local read count: 86494530
Local read latency: 2.646 ms
Local write count: 247712138
Local write latency: 0.030 ms
Pending tasks: 0
Bloom filter false positives: 2182242
Bloom filter false ratio: 0.02251
Bloom filter space used, bytes: 53135136
Bloom filter off heap memory used, bytes: 53135008
Index summary off heap memory used, bytes: 11560419
Compression metadata off heap memory used, bytes: 376092208
Compacted partition minimum bytes: 373
Compacted partition maximum bytes: 802187438
Compacted partition mean bytes: 100465
Average live cells per slice (last five minutes): 37.0
Average tombstones per slice (last five minutes): 0.0

Re: Large Partitions

[shalom sagges]

Thanks Ali!

I use a 13 months TTL on this table. I guess I need to remodel this table.
And I'll definitely try this tool.



On Tue, Apr 3, 2018 at 1:28 AM, Ali Hubail  wrote:

> system.log should show you some warnings about wide rows. Do a grep on
> system.log for 'Writing large partition' The message could be different for
> the c* version you're using though. Plus, this doesn't show you all of the
> large partitions.
>
> There is a nice tool that analyzes sstables and can show the large
> partitions:
> https://github.com/tolbertam/sstable-tools
>
>
> By "how to deal with them?" it depends. If you don't need those
> partitions then you can delete them. You can also use TTL if it fits you or
> remodel your table to only hold upto 100k rows or 100mb per partition
> (whichever comes first). If you're going to remodel the table, aim for much
> less than 100k/100mb per partition.
>
> *Ali Hubail*
>
> Confidentiality warning: This message and any attachments are intended
> only for the persons to whom this message is addressed, are confidential,
> and may be privileged. If you are not the intended recipient, you are
> hereby notified that any review, retransmission, conversion to hard copy,
> copying, modification, circulation or other use of this message and any
> attachments is strictly prohibited. If you receive this message in error,
> please notify the sender immediately by return email, and delete this
> message and any attachments from your system. Petrolink International
> Limited its subsidiaries, holding companies and affiliates disclaims all
> responsibility from and accepts no liability whatsoever for the
> consequences of any unauthorized person acting, or refraining from acting,
> on any information contained in this message. For security purposes, staff
> training, to assist in resolving complaints and to improve our customer
> service, email communications may be monitored and telephone calls may be
> recorded.
>
>
> *shalom sagges >*
>
> 04/02/2018 03:57 PM
> Please respond to
> user@cassandra.apache.org
>
> To
> user@cassandra.apache.org,
>
> cc
> Subject
> Large Partitions
>
>
>
>
> Hi All,
>
> I ran nodetool cfstats (v2.0.14) on a keyspace and found that there are a
> few large partitions. I assume that since "Compacted partition maximum
> bytes": 802187438 (~800 MB) and since
> "Compacted partition mean bytes": 100465 (~100 KB), it means that most
> partitions are in okay size and only a few are large. Am I assuming
> correctly?
>
> If so, can anyone suggest how to find those large partitions and how to
> deal with them? (cfstats output below)
>
> Thanks!
>
>
> nodetool cfstats keyspace1;
>
> Table: table1
> SSTable count: 16
> Space used (live), bytes: 453844035587
> Space used (total), bytes: 453844035587
> Off heap memory used (total), bytes: 440787635
> SSTable Compression Ratio: 0.17417149031966575
> Number of keys (estimate): 33651200
> Memtable cell count: 27966
> Memtable data size, bytes: 41698140
> Memtable switch count: 199727
> Local read count: 86494530
> Local read latency: 2.646 ms
> Local write count: 247712138
> Local write latency: 0.030 ms
> Pending tasks: 0
> Bloom filter false positives: 2182242
> Bloom filter false ratio: 0.02251
> Bloom filter space used, bytes: 53135136
> Bloom filter off heap memory used, bytes: 53135008
> Index summary off heap memory used, bytes: 11560419
> Compression metadata off heap memory used, bytes: 376092208
> Compacted partition minimum bytes: 373
>
> * Compacted partition maximum bytes: 802187438 Compacted partition mean
> bytes: 100465*
> Average live cells per slice (last five minutes): 37.0
> Average tombstones per slice (last five minutes): 0.0
>
>

答复: nodetool repair and compact

[Xiangfei Ni]

Hi James and Jon,
Thank you very much for  your advice, I will go through the article.
By the way,is there any official documentation for instructing the detail of 
nodetool command,the web pages in datastax are just brief instruction.

Best Regards,

倪项菲/ David Ni
中移德电网络科技有限公司
Virtue Intelligent Network Ltd, co.
Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
Mob: +86 13797007811|Tel: + 86 27 5024 2516

发件人: James Shaw 
发送时间: 2018年4月2日 21:56
收件人: user@cassandra.apache.org
主题: Re: nodetool repair and compact

you may use:  nodetool upgradesstables -a keyspace_name table_name
it will re-write this table's sstable files to current version, while 
re-writing, will evit droppable tombstones (expired +  gc_grace_seconds 
(default 10 days) ), if partition cross different files, they will still be 
kept, but most droppable tombstones gone and size reduced.
It works well for ours.



On Mon, Apr 2, 2018 at 12:45 AM, Jon Haddad 
mailto:j...@jonhaddad.com>> wrote:
You’ll find the answers to your questions (and quite a bit more) in this blog 
post from my coworker: 
http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html

Repair doesn’t clean up tombstones, they’re only removed through compaction.  I 
advise taking care with nodetool compact, most of the time it’s not a great 
idea for a variety of reasons.  Check out the above post, if you still have 
questions, ask away.



On Apr 1, 2018, at 9:41 PM, Xiangfei Ni 
mailto:xiangfei...@cm-dt.com>> wrote:

Hi All,
  I want to delete the expired tombstone, someone uses nodetool repair ,but 
someone uses compact,so I want to know which one is the correct way,
  I have read the below pages from Datastax,but the page just tells us how to 
use the command,but doesn’t tell us what it is exactly dose,
  https://docs.datastax.com/en/cassandra/3.0/cassandra/tools/toolsRepair.html
   could anybody tell me how to clean the tombstone and give me some materials 
include the detailed instruction about the nodetool command and options?Web 
link is also ok.
  Thanks very much
Best Regards,

倪项菲/ David Ni
中移德电网络科技有限公司
Virtue Intelligent Network Ltd, co.
Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
Mob: +86 13797007811|Tel: + 86 27 5024 
2516

Re: Execute an external program

[kurt greaves]

Correct. Note that both triggers and CDC aren't widely used yet so be sure
to test.

On 28 March 2018 at 13:02, Earl Lapus  wrote:

>
> On Wed, Mar 28, 2018 at 8:39 AM, Jeff Jirsa  wrote:
>
>> CDC may also work for newer versions, but it’ll happen after the mutation
>> is applied
>>
>> --
>> Jeff Jirsa
>>
>>
> "after the mutation is applied" means after the query is executed?
>
>

Re: auto_bootstrap for seed node

[kurt greaves]

Setting auto_bootstrap on seed nodes is unnecessary and irrelevant. If the
node is a seed it will ignore auto_bootstrap and it *will not* bootstrap.

On 28 March 2018 at 15:49, Ali Hubail  wrote:

> "it seems that we still need to keep bootstrap false?"
>
> Could you shed some light on what would happen if the auto_bootstrap is
> removed (or set to true as the default value) in the seed nodes of the
> newly added DC?
>
> What do you have in the seeds param of the new DC nodes (cassandra.yaml)?
> Do you reference the old DC seed nodes there as well?
>
> *Ali Hubail*
>
> Email: ali.hub...@petrolink.com | www.petrolink.com
> Confidentiality warning: This message and any attachments are intended
> only for the persons to whom this message is addressed, are confidential,
> and may be privileged. If you are not the intended recipient, you are
> hereby notified that any review, retransmission, conversion to hard copy,
> copying, modification, circulation or other use of this message and any
> attachments is strictly prohibited. If you receive this message in error,
> please notify the sender immediately by return email, and delete this
> message and any attachments from your system. Petrolink International
> Limited its subsidiaries, holding companies and affiliates disclaims all
> responsibility from and accepts no liability whatsoever for the
> consequences of any unauthorized person acting, or refraining from acting,
> on any information contained in this message. For security purposes, staff
> training, to assist in resolving complaints and to improve our customer
> service, email communications may be monitored and telephone calls may be
> recorded.
>
>
> *"Peng Xiao" <2535...@qq.com <2535...@qq.com>>*
>
> 03/28/2018 12:54 AM
> Please respond to
> user@cassandra.apache.org
>
> To
> "user" ,
>
> cc
> Subject
> Re:  auto_bootstrap for seed node
>
>
>
>
> We followed this https://docs.datastax.com/en/cassandra/2.1/cassandra/
> operations/ops_add_dc_to_cluster_t.html,
> but it does not mention that change bootstrap for seed nodes after the
> rebuild.
>
> Thanks,
> Peng Xiao
>
>
> -- Original --
> *From: * "Ali Hubail";
> *Date: * Wed, Mar 28, 2018 10:48 AM
> *To: * "user";
> *Subject: * Re: auto_bootstrap for seed node
>
> You might want to follow DataStax docs on this one:
>
> For adding a DC to an existing cluster:
> *https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/operations/opsAddDCToCluster.html*
> 
> For adding a new node to an existing cluster:
> *https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/operations/opsAddNodeToCluster.html*
> 
>
> briefly speaking,
> adding one node to an existing cluster --> use auto_bootstrap
> adding a DC to an existing cluster --> rebuild
>
> You need to check the version of c* that you're running, and make sure you
> pick the right doc version for that.
>
> Most of my colleagues miss very important steps while adding/removing
> nodes/cluster, but if they stick to the docs, they always get it done right.
>
> Hope this helps
>
> * Ali Hubail*
>
> Confidentiality warning: This message and any attachments are intended
> only for the persons to whom this message is addressed, are confidential,
> and may be privileged. If you are not the intended recipient, you are
> hereby notified that any review, retransmission, conversion to hard copy,
> copying, modification, circulation or other use of this message and any
> attachments is strictly prohibited. If you receive this message in error,
> please notify the sender immediately by return email, and delete this
> message and any attachments from your system. Petrolink International
> Limited its subsidiaries, holding companies and affiliates disclaims all
> responsibility from and accepts no liability whatsoever for the
> consequences of any unauthorized person acting, or refraining from acting,
> on any information contained in this message. For security purposes, staff
> training, to assist in resolving complaints and to improve our customer
> service, email communications may be monitored and telephone calls may be
> recorded.
>
> *"Peng Xiao" <2535...@qq.com <2535...@qq.com>>*
>
> 03/27/2018 09:39 PM
>
>
> Please respond to
> user@cassandra.apache.org
>
> To
> "user" ,
>
> cc
> Subject
> auto_bootstrap for seed node
>
>
>
>
>
>
> Dear All,
>
> For adding a new DC ,we need to set auto_bootstrap: false and then run the
> rebuild,finally we need to change auto_bootstrap: true,but for seed
> nodes,it seems that we still need to keep bootstrap false?
> Could anyone please confirm?
>
> Thanks,
> Peng Xiao
>