(Anyone who wants something more reliable than just a backup that you have to try and figure out how to restore last minute)
For normal setups,
1) What do you do when you arrive on Monday morning and the server is broken and not working?
2) How fast can you build a new server or restore all your data to a new machine?
---I faced these issues multiple times when I relied on just a normal windows computer or single Linux computer for my server.
---All computers go down at some point, it is just a matter of time.
My Proxmox/Ceph 5 computer setup (Xeon CPUS originally, moved to normal Ryzen 9 CPUs for my replacement servers) setup has been so reliable over the past 10 years that I have had and maintained it. I have not had one day of downtime in my office due to loss of servers, even though I have lost multiple computers at various times due to hardware failure. I just take that computer/node out of service and usually I don't even fix it right away, but over the few weeks time as time allows. This is because of the distributed storage system, it all works fantastic and keeps going even if I loose one or even two more machines or disks on machines. I will then either fix the issue (reinstall proxmox on a new drive and and plug it back in. or build a new server, add it to the cluster and boom, back up with all the nodes again. All the while OD can be running the whole time with NO downtime at all!
***********************
Just this week, for my Open Dental database, I moved my from my Linux/Proxmox LXC container of mysql 5.5 (no longer supported or updated) to a MariaDB v11.8.3 LXC container on Proxmox v9.1.4.
I am using innoDB with a an Nvme based distributed CEPH v19.2.3 storage backend over 5 separate machines for EXCELLENT HIGH AVAILABILTY, even if I loose up to three of the five machines for whatever reason or when disks fail; and disks do fail, usually at the worst time for all of us!
When I was running this new MariaDB server stock, with no tweaks, running a yearly income & production report did lag quite a bit...it took about 10 seconds for it to load, way slower than the old myISAM setup w/ mysql 5.5 that took probably 1.5 seconds to run. I thought it wasn't going to work until....
After some tuning using Grok and Gemini, it is lightning fast for all normal usage of OD and in multiple days of using it, have had no incompatibilities with this newer version of MariaDB than is officially supported.
Running reports, such as yearly production is an INSTAINTAINOUS load on all modern machines...but still takes about 1 second to calculate on an older desktop machine, I guess lots of the calculations depend on or occur on the local machine speed? Running the A/R report with Aging calculations, still takes about 6 seconds from click to display.
Here are the MariaDB & CEPH tuning specifics that I added to load the entire DB into my server's memory for speed as well as other tweaks:
/etc/mysql/mariadb.conf.d/50-server.cnf
Code: Select all
[mariadbd]
# --- OpenDental Specific Compatibility ---
# lower_case_table_names = 1 # be sure you set this BEFORE copying the data to the database on install
max_allowed_packet = 256M
max_connections = 500
# --- I/O Parallelism (Ceph thrives on this) ---
# Since Ceph handles multiple OSDs, let MariaDB use more threads for I/O
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 2000 # NVMe Ceph can handle high IOPS
innodb_io_capacity_max = 4000
innodb_thread_concurrency = 0 # Let it use all CPUs
innodb_file_per_table = 1
innodb_log_file_size = 1G # Larger for write-heavy; 512M-2G common
# --- Latency Mitigation ---
# Set to 2 to avoid waiting for a network round-trip on every single small commit.
# This is the BIGGEST speed boost for OpenDental on Ceph.
innodb_flush_log_at_trx_commit = 2
# --- Caching (The "Mask") ---
# We want to keep as much as possible in RAM so we don't have to ask Ceph for it.
# Assuming 16GB RAM for the CT:
innodb_buffer_pool_size = 12G # Adjust to ~75% of your CT RAM
innodb_buffer_pool_instances = 12 # 1 instance per GB is a good rule for concurrency
# --- Large Query/Join Performance ---
join_buffer_size = 32M # Bigger helps with those massive "Report" queries
sort_buffer_size = 32M # Helps with ORDER BY operations in OpenDental
max_heap_table_size = 128M
# Caching (improves repeated queries)
table_open_cache = 2048 # More open tables = faster access
thread_cache_size = 16 # Reuse threads for connections
thread_concurrency = 8
Code: Select all
[client]
rbd_cache = true # be sure to have good UPS to avoid data loss
rbd_cache_size = 536870912 # 512MB cache
rbd_cache_max_dirty = 402653184 # Max 384MB dirty data before flushing
rbd_cache_target_dirty = 268435456 # Start flushing at 256MB
rbd_cache_max_dirty_age = 1.0 # Max 1 second delay