That sounds like a possibility to me on the surface. Kind Regards, Brandon
On Fri, Dec 20, 2024 at 8:42 AM Paul Chandler <p...@redshots.com> wrote: > > Hi Brandon, > > That sounds good. Will that fix be in 4.1, as it is the old nodes that don’t > transmit the hints? > > Thanks > > Paul > > > On 20 Dec 2024, at 13:41, Brandon Williams <dri...@gmail.com> wrote: > > > > I think after a discussion on #cassandra-dev yesterday, we are going > > to remove the requirement for schema agreement to deliver hints, as > > suggested by Jeff Jirsa. > > > > Kind Regards, > > Brandon > > > > On Thu, Dec 19, 2024 at 7:43 AM Paul Chandler <p...@redshots.com> wrote: > >> > >> Hi Brandon, > >> > >> I am not sure which part changes after CASSANDRA-20118, there is still the > >> system mismatch going to CASSANDRA_4 caused by the change in > >> system.compaction_history, and going to UPGRADING, this is caused by the 2 > >> different sstable formats, so nothing that CASSANDRA-20118 fixes. > >> > >> So while CASSANDRA-20118 improves things, it does not fix these specific > >> issues, unless I have missed something? > >> > >>> On 19 Dec 2024, at 12:17, Brandon Williams <dri...@gmail.com> wrote: > >>> > >>> On Thu, Dec 19, 2024 at 4:11 AM Paul Chandler <p...@redshots.com> wrote: > >>>> C*4 -> CASSANDRA_4 : There is a schema mismatch, and hints are not sent > >>>> from C*4 node to C*5 nodes. > >>>> CASSANDRA_4 -> UPGRADING: Repairs are not possible and Nodes cannot be > >>>> added or replaced. > >>>> UPGRADING-> NONE: No issues. > >>> > >>> I'll note this will change after CASSANDRA-20118 > >>> > >>>> Any thoughts on whether having SCM controlled by JMX/nodetool is a good > >>>> idea? > >>> > >>> I think it's a good idea but it's tricky. As I said on 20118, "An > >>> unfortunate consequence of our use of static initialization is that > >>> once started, there is no way to change storage compatibility modes" > >>> and all the columns are defined statically, so that will have to be > >>> overcome. > >>> > >>> Kind Regards, > >>> Brandon > >> >