This snitch is easy to misconfigure. It allows some nodes to have a different view of the cluster if they are configured differently, which can result in data loss (or at least data that is very hard to recover). Also it has a nasty feature that allows to set a default DC/Rack. If one node isn't properly declared in all the files throughout the cluster, it will be seen as part of that "default" DC and then again, it's hard to recover. Be aware that while the GossipingPropertyFileSnitch will not allow changing rack of DC for a node that already bootstrapped, the PropertyFileSnitch will allow to change it without any notice. So a little misconfiguration could merge all nodes from DC1 into DC2, abruptly changing token ownership (and it could very be the case that DC1 thinks it's part of DC2 but DC2 still thinks DC1 is DC1). So again, I think this snitch is dangerous and shouldn't be used. The GossipingPropertyFileSnitch is much more secure and easy to use.
Cheers, On Wed, Feb 27, 2019 at 10:13 AM shalom sagges <shalomsag...@gmail.com> wrote: > If you're using the PropertyFileSnitch, well... you shouldn't as it's a > rather dangerous and tedious snitch to use > > I inherited Cassandra clusters that use the PropertyFileSnitch. It's been > working fine, but you've kinda scared me :-) > Why is it dangerous to use? > If I decide to change the snitch, is it seamless or is there a specific > procedure one must follow? > > Thanks! > > > On Wed, Feb 27, 2019 at 10:08 AM Alexander Dejanovski < > a...@thelastpickle.com> wrote: > >> I confirm what Oleksandr said. >> Just stop Cassandra, change the IP, and restart Cassandra. >> If you're using the GossipingPropertyFileSnitch, the node will redeclare >> its new IP through Gossip and that's it. >> If you're using the PropertyFileSnitch, well... you shouldn't as it's a >> rather dangerous and tedious snitch to use. But if you are, it'll require >> to change the file containing all the IP addresses across the cluster. >> >> I've been changing IPs on a whole cluster back in 2.1 this way and it >> went through seamlessly. >> >> Cheers, >> >> On Wed, Feb 27, 2019 at 8:54 AM Oleksandr Shulgin < >> oleksandr.shul...@zalando.de> wrote: >> >>> On Wed, Feb 27, 2019 at 4:15 AM wxn...@zjqunshuo.com < >>> wxn...@zjqunshuo.com> wrote: >>> >>>> >After restart with the new address the server will notice it and log a >>>> warning, but it will keep token ownership as long as it keeps the old host >>>> id (meaning it must use the same data directory as before restart). >>>> >>>> Based on my understanding, token range is binded to host id. As long as >>>> host id doesn't change, everything is ok. Besides data directory, any other >>>> thing can lead to host id change? And how host id is caculated? For >>>> example, if I upgrade Cassandra binary to a new version, after restart, >>>> will host id change? >>>> >>> >>> I believe host id is calculated once the new node is initialized and >>> never changes afterwards, even through major upgrades. It is stored in >>> system keyspace in data directory, and is stable across restarts. >>> >>> -- >>> Alex >>> >>> -- >> ----------------- >> Alexander Dejanovski >> France >> @alexanderdeja >> >> Consultant >> Apache Cassandra Consulting >> http://www.thelastpickle.com >> > -- ----------------- Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com
