Production Deployment & Operations
Module Duration: 5-6 hours
Learning Style: Configuration + Monitoring + Troubleshooting
Outcome: Deploy and operate production Neo4j clusters with HA and performance
Neo4j Deployment Options
1. Single Instance: Development, testing 2. Causal Cluster: Production HA (3+ servers) 3. Neo4j Aura: Managed cloud service 4. Fabric: Multi-database federation (sharding)Part 1: Causal Clustering Architecture
How It Works
- Handle writes (via Raft leader election)
- Minimum 3 servers (tolerate 1 failure)
- Recommended: 5 or 7 (tolerate 2 or 3 failures)
- Asynchronous replication from core servers
- Scale read throughput
- Can be added/removed dynamically
Configuration
neo4j.conf (Core Server):Starting a Cluster
Part 2: Routing and Load Balancing
Bolt Routing
Driver Configuration (Python):External Load Balancer
For additional control, use HAProxy: haproxy.cfg:Part 3: Backup and Recovery
Online Backup
Full Backup:Restore from Backup
Disaster Recovery Strategy
3-2-1 Rule:- 3 copies of data (production + 2 backups)
- 2 different storage types (local + cloud)
- 1 off-site backup (S3, Azure Blob, etc.)
Part 4: Monitoring
Built-In Metrics (JMX)
Enable JMX:Prometheus + Grafana
1. Install Neo4j Prometheus Plugin:Key Metrics to Monitor
Part 5: Performance Tuning
JVM Configuration
Heap Size (neo4j.conf):Page Cache
Size Recommendation: 50-75% of remaining RAM (after heap)Transaction Log
Configuration:Part 6: Security
Authentication
Enable authentication:Authorization (RBAC)
Create custom role:Encryption
SSL/TLS for Bolt:Part 7: Troubleshooting
Issue 1: Slow Queries
Diagnosis:- Add indexes
- Use PROFILE to find bottlenecks
- Rewrite query (filter early, limit results)
Issue 2: High Memory Usage
Diagnosis:- Increase heap size (dbms.memory.heap.max_size)
- Increase page cache (dbms.memory.pagecache.size)
- Check for transaction leaks (unclosed transactions)
Issue 3: Cluster Split-Brain
Symptom: Multiple leaders elected Diagnosis:- Use odd number of core servers (3, 5, 7)
- Ensure network stability
- Configure causal_clustering.minimum_core_cluster_size_at_runtime correctly
Issue 4: Replication Lag
Diagnosis:- Add more read replicas
- Increase network bandwidth
- Tune causal_clustering.catchup.batch_size
Part 8: Best Practices Checklist
Deployment:- Use causal cluster (3+ core servers)
- Configure read replicas for read scaling
- Use Bolt routing in drivers
- External load balancer (HAProxy) for fine control
- Automated daily backups
- Off-site backup to S3/cloud
- Tested restore procedure
- 30-day retention
- Prometheus + Grafana setup
- Alerts for key metrics (transactions, GC, lag)
- Query logging enabled (threshold: 1s)
- Heap: 8-16GB
- Page cache: 50-75% of RAM
- Page cache hit ratio > 95%
- Indexes on frequently queried properties
- Authentication enabled
- RBAC configured (least privilege)
- SSL/TLS for Bolt
- Firewall rules (only necessary ports open)
Summary
Causal Clustering: 3+ core servers for HA, read replicas for scale Backup: Automated daily backups with off-site storage Monitoring: Prometheus + Grafana for metrics Performance: Proper heap/cache sizing, GC tuning Security: Authentication, RBAC, SSL/TLS Production-Ready: HA, monitored, secured, backed up, performant!What’s Next?
Module 8: Capstone Project - Knowledge Graph Platform
Build a complete knowledge graph application with recommendations, search, and analytics