1. Inicio
  2. Pregunta y respuesta
  3. Recomendaciones y técnicas de replicación de Muzak

Recomendaciones y técnicas de replicación de Muzak

2011-08-27 18 views
19

Estoy intentando mi primer proyecto de base de datos a gran escala por mi cuenta. Tengo myisam mysql db en el servidor 1 con una aplicación php que consume una gran cantidad de datos. Tengo mysql myisam en el servidor 2 con la aplicación php seleccionando y mostrando datos.Recomendaciones y técnicas de replicación de Muzak

que desea replicar estos datos en el servidor 2.

Preguntas:

  1. ¿Debo cambiar de servidor de base de datos mysql 1 a InnoDB
  2. ¿Se puede replicar innodb server1 a server2 myisam
  3. I Estoy almacenando los medios como blobs con la intención de usar el caché para descargar el estrés en el servidor en vivo. ¿Debo usar el almacenamiento del sistema de archivos y rsync?
  4. ¿Algún consejo general de otras personas con experiencia?

Fuente

2011-08-27 user915831

Respuesta

26

Esto es lo que sugiero basado en mi experiencia.

  1. Puede utilizar un tipo de motor (MyISAM o InnoDB) para ambos servidores. Yo mezclo ambos motores, es posible que tengas un punto muerto, problemas de transacción, etc. ... y el tiempo de solucionarlos puede ser doloroso. Tuve problemas hace un tiempo con InnoDB -> MyISAM. Ahora utilicé MyISAM en todos los servidores.

  2. Para almacenar medios (como imágenes, video o documentos) puede crear un NFS y montar una carpeta como/usermedia/a la que acceden ambos servidores. Por lo tanto, no es necesario que sincronice todo el tiempo. Además, puede guardar los metadatos o información de medios en la base de datos para referencia y dónde se guarda el archivo en el disco. Nota: usar un blob para guardar archivos puede ser bueno dependiendo de los medios. Si tiene un archivo que tiene aproximadamente 1 gig, puede que no sea una buena idea guardarlo en la base de datos, por ejemplo).

  3. Utilice un sistema de almacenamiento en caché para recuperar datos (como memcached). Por ejemplo, si solicita datos y necesita mostrarlos al usuario, primero mire en la caché. Si no está en la memoria caché, consulte la base de datos, guárdela en la memoria caché y visualícela. La próxima vez que se solicite la misma información, no la solicitará desde el servidor, sino desde la memoria. Esta solución evitará numerosas llamadas al servidor de la base de datos, lo que mejorará el rendimiento.

Avíseme si necesita ayuda adicional.

Fuente

2011-08-27 20:49:52

+0

Gracias. Los archivos multimedia son imágenes. 3 versiones de la misma imagen en diferentes tamaños. El tamaño del archivo varía entre 10k y 80k y no es mucho más que eso. Con eso en mente, seguirá teniendo un gran tamaño de base de datos. ¿Eso importa? O es mysql lo suficientemente fuerte para el trabajo. Por supuesto, memcached se utilizará en el lado vivo. – user915831

+0

Me gusta la idea de nfs. Pero como se trata de un proyecto personal, mis fondos son limitados. Tengo un buen servidor dedicado en vivo. En un centro de datos con ancho de banda no medido y conexión t1. Tengo un servidor interno en la oficina, pero está restringido por la conexión ascendente de Internet, que tiene una velocidad de entre 512 y 20mb hacia abajo. Entonces, con esta conexión de icono, la conexión nfs en el servidor interno ralentizará el software consumidor, ¿no? – user915831

+0

¿Los servidores están en el mismo centro de datos? ¿Pueden hablar entre ellos sin VPN? revisa estos enlaces http://how-to.linuxcareer.com/how-to-configure-nfs-on-linux. Tal vez pueda comenzar a almacenar imágenes en la base de datos ya que son pequeñas y luego pasar a la solución NFS si actualiza a medios más grandes. –

23

recomendaría InnoDB (para transacciones, el bloqueo de filas y no la tabla de bloqueo) y Redis como el almacenamiento en caché muy rápido y eficiente

Fuente

2011-10-16 23:13:20

Cuestiones relacionadas

 Cuestiones relacionadas