As I remember, GET_LOCK is supported if wsrep_on is ON in latest mariadb versions.
-Wei On Wednesday, August 14, 2024, Joan g <joang...@gmail.com> wrote: > As Rohit mentioned, since the GET_LOCK function isn't supported here, could > there be a risk of inconsistency* if both managers update the same row > simultaneously*? > > @João Jandre Paraquetti Thank you pointing out I was connecting to 'cloud' > DB for db.usage.uri > > > Jon > > On Wed, Aug 14, 2024 at 9:59 AM Rohit Yadav <rohit.ya...@shapeblue.com> > wrote: > > > Worth mentioning here that due to GET_LOCK limitations you may not use > > your db cluster in active-active configuration. > > > > Regards. > > > > > > > > ________________________________ > > From: Marty Godsey <mar...@rudio.net> > > Sent: Tuesday, August 13, 2024 11:22:47 PM > > To: users@cloudstack.apache.org <users@cloudstack.apache.org> > > Subject: Re: Cloudstack 4.19 Behavior with MariaDB Galera Cluster > > > > I use a Galera Cluster for my DB, which works without issue. I do not, > for > > other reasons, load balance. It is set to failover. Before I had to make > > this change, I used load balance, and it worked fine, however. > > > > Regards, > > Marty Godsey > > > > > > From: João Jandre Paraquetti <j...@scclouds.com.br> > > Date: Tuesday, August 13, 2024 at 1:46 PM > > To: users@cloudstack.apache.org <users@cloudstack.apache.org> > > Subject: Re: Cloudstack 4.19 Behavior with MariaDB Galera Cluster > > WARNING: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe. > > > > > > Hello Jon, > > > > Whether there will be randomness or not depends on your setup. As far as > > I know, there are two possible modes for the connection with Galera > > clusters: sequential and loadbalance. With the sequential mode, the > > connector will try to connect to hosts in the order in which they were > > declared in the connection URL, so no randomness. Using the loadbalance > > mode, the connector performs load-balancing for all queries by randomly > > picking a host from the connection URL for each connection, so even with > > all hosts up, you'll have random connections. > > > > Regarding whether random connections are a problem, since you'll be > > using a Galera cluster, any MariaDB node should be basically the same > > (from the mgmt servers perspective), as all data is replicated, so it > > does not really matter which one is used. I don't see any problem with > > different mgmt servers connecting to different MariaDB nodes that are on > > the same Galera cluster. > > > > Could you share the value that you configured for db.usage.uri? please > > make sure that you are connecting to the cloud_usage DB and not the > > cloud DB. > > > > Best regards > > > > João Jandre > > > > On 8/13/24 08:24, Joan g wrote: > > > Hello Community, > > > > > > I am trying to explore the mariadb flexible URI introduced in 4.19 Ref: > > > > > https://atpscan.global.hornetsecurity.com?d=-s6c4P8H0F-6- > lmZZ6U00SpQrMbRGp0imtCmO17q9oA&f=SWvzu6arJFaC7g8oD58dV- > rNUGDjTikFIHTyuWVLU7GWtnNyMz6Tg6x1Z2wjH2Zw&i=&k=Ie9V&m=jUm3E2gaksTIskF_ > WQRJEDhPUC8imjmYn5p6CgRIz4HqqTgZR46VEfxgYcZ4WOeDSSi30TuzzkpM7H- > MjQmDfubymBkJ5ggkbm1wjD6mwd7HpdXHHnYDkyKCXoMGsSTE&n= > OD2YhJhOuOTBvltNv5vw7yY5G1B0ApS-wcJDDiSNEKF9kUMWcZo4ux2s7IMzOwcL&r= > CujZfpt5OxUjowOuEiunB9ROUBFRuQ2BIvaP-f6zEKC3KLuhFgDPL3jXADWhIqyQ&s= > 100aa56155ed1380bc3f081e5584c81a68ecac1ca324e8940189c7bb1089 > 2f3a&u=https%3A%2F%2Fgithub.com%2Fapache%2Fcloudstack%2Fpull%2F7895 > > > My concern is on deployment with 2 or 3 Cloudstack management Servers. > > > > > > In the event of a server failure or restart, there's a possibility that > > > each management service could connect to different MariaDB hosts. Is > this > > > behavior acceptable? Will it cause any issues with the database? I've > > heard > > > that all management servers should connect to the same MariaDB host. > > > > > > Also Usage service is failing to start using db.usage.uri, management > is > > > fine > > > > > > Jon > > > > > >
