- Products
- Learn
- Local User Groups
- Partners
- More
Scaling Check Point Automation with Arodonata
7 October @ 5pm CET / 11am EDT
AI Security Masters
LGTM: Bypassing an LLM Build Gate
When Prompt Injection Fails
What's New in Check Point SASE
The State of Ransomware Q2 2026:
This Quarter's Trends, and Their Impact on Your Defenses
CheckMates Go:
Half is Not Enough
Hi Everyone,
We’ve set up an ElasticXL cluster (R82) and successfully installed the hotfix on Gateway1. However, Gateway2 fails with a “db error” during installation.
What we’ve tried:
We suspect this might be related to database sync issues or corruption on Gateway2. Has anyone seen this before in ElasticXL setups? Is there a recommended way to reset or reinitialize the local DB without affecting the SMO
Any insights or SKs would be appreciated.
Thanks in advance!
Just to double check, are you following the documented procedure for installation?
If so and it's still not working, might need a TAC case raised to investigate deeper.
Just to double check, are you following the documented procedure for installation?
If so and it's still not working, might need a TAC case raised to investigate deeper.
Im 100% sure you need to follow exactly what @emmap sent. I had exact same issue with customer recently an that was the solution, disable auto clone feature.
Andy
Pretty sure I did this (I was on a zoom with TAC) and issue was replicated, hence they are going to lab this as well.
What is the output of below in clish?
show smo image auto-clone state
Andy
I've actually got a TAC running for this - the Engineer is labing this issue.
When I had case with customer for this exact issue, TAC asked us to do the same thing Emma mentioned and that fixed it.
Andy
I have a TAC case running for this exact issue!
Also can we get this moved to the thread I created " R82 ElasticXL & VSNext Issues"
b.t.w - just installed another two Nodes in my lab, this time with JHFA33 and in ClusterXL/VSX mode, so far no issues to report.
Good news!
Still early but this suggests to me that R82 using traditional technologies would be a safer deployment for production setups, at this stage. I do have every confidence in ElasticXL and VSNext as superior replacements at some point in the near future.
It would certainly be worth Checkpoint investigating the conversion path from VSX to VSNext and ClusterXL to ElasticXL (100% sure this would not be easiest thing).
Only reason I suggested that so that issues related to ElasticXL and VSNext could be held under one thread.
@Chris_Atkinson @genisis__ I confirm that we cannot merge threads. Concerning the tags, one can use any tags on any post.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 34 | |
| 8 | |
| 6 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 4 | |
| 3 |
Thu 01 Oct 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point WAF | Preventing minus-zero-day attacksTue 06 Oct 2026 @ 12:00 PM (ACDT)
Rethinking Network Security for the AI Era : Session 2 - From User, to Branch and Campus APACTue 06 Oct 2026 @ 03:00 PM (CEST)
Rethinking Network Security for the AI Era : Session 2 - From User, to Branch and Campus EMEAThu 01 Oct 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point WAF | Preventing minus-zero-day attacksTue 06 Oct 2026 @ 12:00 PM (ACDT)
Rethinking Network Security for the AI Era : Session 2 - From User, to Branch and Campus APACTue 06 Oct 2026 @ 03:00 PM (CEST)
Rethinking Network Security for the AI Era : Session 2 - From User, to Branch and Campus EMEATue 06 Oct 2026 @ 02:00 PM (EDT)
Rethinking Network Security for the AI Era : Session 2 - From User, to Branch and Campus AMERAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY