base de datos para la redundancia utilizando una base de datos libre y una de Java con la aplicación web de Primavera y Hibernate

Question

tengo esto en mente:

En cada servidor: (que todo se estableció idéntica)

• Una base de datos libre como MySQL o PostgreSQL.
• Tomcat 6.x para el alojamiento de aplicaciones Java basado en Servlet
• Hibernate 3.x como la herramienta ORM
• Spring 2,5 para la capa de negocio
• Wicket 1.3.2 para la capa de presentación

Coloco un equilibrador de carga en frente de los servidores y un balanceador de carga de reemplazo en caso de que mi equilibrador de carga primario se caiga.

Uso Terracotta para tener la información de sesión replicada entre los servidores. Si un servidor se cae, el usuario debería poder continuar su trabajo en otro servidor, idealmente como si nada hubiera sucedido. Lo que queda por "resolver" (ya que en realidad no lo he probado y, por ejemplo, no sé qué usar como equilibrador de carga) es la replicación de la base de datos que se necesita.

Si un usuario interactúa con la aplicación y la base de datos cambia, entonces ese cambio debe replicarse en los servidores de la base de datos en las otras máquinas servidoras. ¿Cómo debo hacer eso? ¿Debo usar MySQL PostgreSQL o algo más (que idealmente es gratis ya que tenemos un presupuesto limitado)? ¿Las otras cosas anteriores suenan sensatas?

Aclaración: Me centro para obtener una alta disponibilidad antes que nada y deseo poder agregar servidores y usarlos todos al mismo tiempo para obtener una alta escalabilidad.

Answer 1

Dado que ya está utilizando Terracotta, y cree que una segunda base de datos es una buena idea (de acuerdo), puede considerar ampliar la función de Terracotta. Tenemos clientes que usan Terracotta para la replicación de la base de datos. He aquí un ejemplo breve/descripción, pero creo que han dejado de apoyar a los clientes de este producto .:

http://www.terracotta.org/web/display/orgsite/TCCS+Asynchronous+Data+Replication

Answer 2

Aquí hay una idea. Lea el libro de Theo Schlossnagle Salable Internet Architectures.

Lo que estás proponiendo no es la mejor idea.

Los equilibradores de carga son caros y no tan valiosos como podrían parecer. Use algo más simple para distribuir la carga entre sus servidores (algo así como Wackamole).

En lugar de perder el tiempo con la replicación de bases de datos, gaste su dinero en un servidor de bases de datos confiable independiente de los servidores web front-end. Haga copias de seguridad periódicas y en el caso poco probable de falla de la base de datos, vuelva a ejecutar lo más rápido posible desde las copias de seguridad normales.

Answer 3

Para mi sitio web (dirigido por Perl), estoy usando MySQL en dos servidores con replicación de base de datos. Cada servidor MySQL es esclavo y maestro al mismo tiempo. Hice esto para la redudancy, no para el rendimiento, pero la configuración ha funcionado bien durante los últimos 3 años, casi no tuvimos tiempo de inactividad durante este período.

En relación con la pregunta/comentario de Kent: Estoy usando la replicación estándar que viene con MySQL.

En cuanto al mecanismo de conmutación por error: Estoy usando DNSMadeEasy.Funcionalidad de failover de com. Tengo un script de Perl ejecutado cada 5 minutos a través de cron que comprueba si la replicación aún se está ejecutando (y también muchas otras cosas como la carga del servidor, la cordura del HDD, el uso de la RAM, etc.). Durante el funcionamiento normal, el más rápido de los dos servidores entrega todas las páginas web. Si el script detecta que algo anda mal con el servidor (o si el servidor está simplemente inactivo), DNSMadeEasy cambia las entradas de DNS para que el servidor secundario se convierta en primario. Una vez que el servidor primario "real" es respaldado, MySQL automáticamente se da cuenta de los cambios de base de datos que faltan y DNSMadeEasy automáticamente cambia.

Answer 4

Usted está tratando de crear una réplica con varios maestros, que es una muy mala idea, ya que cualquier cambio en cualquier base de datos tiene que replicarse en cualquier otra base de datos. Esto es terriblemente lento: en un servidor puede obtener varios cientos de transacciones por segundo usando un par de discos rápidos y RAID1 o RAID10. Puede ser mucho más si tiene un buen controlador RAID con caché respaldado por batería. Si agrega la sobrecarga de comunicarse con todos sus servidores, obtendrá como máximo decenas de transacciones por segundo.

Si desea alta disponibilidad, debe optar por una solución de reserva activa, donde tiene un servidor, que se replica pero no se utiliza: cuando el servidor principal muere, se reemplaza una sustitución. Puede perder algunas transacciones recientes si su servidor principal fallece.

También puede optar por una replicación asíncrona maestra, múltiple de esclavos. Cada cambio a una base de datos tendrá que realizarse en un servidor maestro. Pero puede tener varios servidores esclavos de solo lectura. Los datos en este servidor esclavo pueden ser varias transacciones detrás del maestro, por lo que también puede perder algunas transacciones recientes en caso de muerte del servidor.

PostgreSQL tiene ambos tipos de replicación: modo de espera en caliente mediante el envío de registros y un maestro, varios esclavos usando slony.

Solo si tiene un número muy reducido de escrituras, puede optar por la replicación sincrónica. Esto también se puede configurar para PostgreSQL usando PgPool-II o Sequoia.

Lea el capítulo High Availability, Load Balancing, and Replication en la documentación de Postgres para obtener más información.

Answer 5

AFAIK, MySQL hace un mejor trabajo siendo escalable. Consulte la documentación http://dev.mysql.com/doc/mysql-ha-scalability/en/ha-overview.html

Y no es un blog, donde se puede echar un vistazo a los ejemplos de la vida real: http://highscalability.com/tags/mysql