El foro de caduceus.es ha sido migrado a meditecs.com. Descubre más sobre el cambio en este post.
🇬🇧 English speaker? Go to Meditecs forums in English!
Recientemente hemos recibido esta pregunta de una visitante de nuestra web, que reproduzco aquí ya que considero que es un tema interesante sobre el que debatir:
He leído en varios sitios que la instalación de Mirth se plantea sobre un servidor con Linux, Windows o MacOS. Mirth tiene una BD embebida. De modo que en este planteamiento la escalabilidad sería vertical (incrementando recursos), y además en caso de fallo habría parada de servicio hasta recuperar/solucionar el problema.
La pregunta es, ¿cómo resolver la escalabildad horizontal, y dado que Mirth tiene un BD embebida, ¿cuál sería el planteamiento para garantizar la continuidad de servicio?
Interesante tema, nosotros siempre tratamos de migrar a SQLSERVER cuando preveemos que la base de datos va a crecer durante el tiempo que tengamos el contrato con el cliente.
La base de datos embebida Derby está desaconsejada para usos en producción por los mismos desarrolladores (wiki). Es por esto que Mirth ofrece la posibilidad de cambiar la base de datos cómodamente desde la aplicación Server Manager, o directamente sobre el archivo de configuraciones '.../mirth_directory/conf/mirth.properties
De esta forma, no sólo mejoraremos la eficiencia da la base de datos, si no que también tendremos la opción de usar una base de datos remota, que esté ubicada en un servidor con más recursos.
Buenas. En mi experiencia de uso en produccion yo la he puesto siempre en MySql y ha sido bastante positiva. Haciendo tareas de mantenimiento adecuadas como pruning de canales es bastante robusta. Como dice el compañero, dejar derby por defecto es desaconsejado. Saludos a todos