Re: Arquitectura P2P entre servidores
El 12 de diciembre de 2010 13:35, Julian julian.reyes.escri...@gmail.comescribió: y donde podria encontrar algo de dcumentacion sobre el proceso de repliegue de informacion creo que aun falta que indiques mas datos acerca de que es lo que realmente necesitas hacer, ya que lo del servidor central vs. servidores secundarios suena a una solucion ya encaminada. si todos los servidores estan fisicamente apartados, y necesitas sincronizar sus datos, una solucion podria ser algo tan simple como que una vez al mes se envien (por SSH) los nuevos datos desde los servidores secundarios en archivos de texto y estos luego son cargados en el servidor central, a su vez desde el servidor central se envian sus nuevos datos a los servidores secundarios tambien mediante archivos de texto. si te quieres complicar con algo mas avanzado puedes revisar el siguiente articulo [1] acerca de como implementar la replicacion circular en MySQL. posiblemente encuentres una guia similar para Postgres, pero insisto que antes deberias analizar bien que es lo que realmente necesitas y buscar la solucion mas simple. [1] http://onlamp.com/onlamp/2006/04/20/advanced-mysql-replication.html -- Ricardo Mun~oz A. http://www.tux.cl
Re: Arquitectura P2P entre servidores
te comento es una aplicacion que va a funcionar en uno de los departamentos de mi pais, donde se va recolectar información madiante digitación de unas encuentas, pero obviamente una persona puede ser encuestada en un lugar distinto y luego encuentada en otro momento en otra ciudad creando una duplicidad que es lo que quieren evitar con este sistema. se sugirio que el sistema estuviera totalmente centralizado, es la mejor opcion, pero hay municipios (ciudades), que por X o Y motivo pueden o tiene problemas de conectividad, y necesitan que el trabajo no se suspenda por falta de internet, en otras palabras desean la maxima disponibilidad posible. las personas que plantearon los requisitos estoy completamente seguro que no tiene las minima idea de lo que solicitaron en los terminos del contrato pero el contrato debe cumplir a cabalidad lo que se exige o al menos una solucion aproximada porque si no se incumpliria en el mismo. vuelvo y se que las bases de datos se pueden poner a trabajar de una manera que cada servidor se conumique con los demas, pero estoy seguro que este tipo de configuracion son para que siempre tengan conexion. digamos que la solucion que tengo en mente hasta el momento es la siguiente servidor secundario 1. la persona trabaja sobre un servidor secundario 2. al momento de procesar la informacion el intenta comunicar al servidor central si no hay conexion se guardan los cambios como si se tratase de una CVS. 3. una tarea programada de cada 15 minutos (por ejemplo) revisa si existen datos que sincronizar si existe conexion los sincroniza servidor central 1. el servidor central recibe peticiones de un servidor secundario hace validaciones a los datos y regresa una novedad de dicho registro 2. si no existe conexion con el servidor secundario guarda las respuesta en algun lugar 3. si existe una confrontacion de informacion con otros sistemas el servidor genera las novedades de cada servidor secundario 4. una tarea programa de cada 15 minutos (por ejemplo) revisa que exista conexion entre el y los servidores secundarios si existe envia las novedades a quien corresponda pues mirandolo de este modo se utilizara algun protocolo para que una tarea programa (cron) envie la informacion cuando exista conexion, el resto simple aplicaciones, la diferencia es que el servidor principal seria nada mas web services para los demas servidores. yo tengo esta idea pero me gustaria conocer cuales serian esos metodos de comunicacion como web services escuche una recomendacion de REST de alguien y si estuve mirandola como la solucion viable, tamiben escuche algo con protocolo torrent, me llama mas la atencion ya que el torrent puede tener las conexiones cifradas y ademas en caso de que la conexion se caiga en plena transferencia no se pierde los transferido ya que una vez se haga la confrontacion pueden llegar a ser grandes cantidades de datos las tranferidas
Re: Arquitectura P2P entre servidores
El 13 de diciembre de 2010 11:40, Julian Reyes Escrigas julian.reyes.escri...@gmail.com escribió: [...] digamos que la solucion que tengo en mente hasta el momento es la siguiente servidor secundario 1. la persona trabaja sobre un servidor secundario 2. al momento de procesar la informacion el intenta comunicar al servidor central si no hay conexion se guardan los cambios como si se tratase de una CVS. 3. una tarea programada de cada 15 minutos (por ejemplo) revisa si existen datos que sincronizar si existe conexion los sincroniza servidor central 1. el servidor central recibe peticiones de un servidor secundario hace validaciones a los datos y regresa una novedad de dicho registro 2. si no existe conexion con el servidor secundario guarda las respuesta en algun lugar 3. si existe una confrontacion de informacion con otros sistemas el servidor genera las novedades de cada servidor secundario 4. una tarea programa de cada 15 minutos (por ejemplo) revisa que exista conexion entre el y los servidores secundarios si existe envia las novedades a quien corresponda en tu mail original decias que la sincronizacion debia hacerse una vez al mes... ahora indicas que deberia ser cada 15 minutos? -- Ricardo Mun~oz A. http://www.tux.cl
Re: Arquitectura P2P entre servidores
Ricardo te has confundido te explico en el mail inicial escribi que una vez al mes el servidor central va a tener una confrontacion de la informacion de la base de datos con la base ded atos de otros sistemas pero aparte de eso los usuarios van a alimentar los servidores secundarios que estos deben a su vez alimentar el principal, es logico que la informacion de los servidores secundarios deben llegar en algun momento al principal de esto debe ser lo mas pronto posible
Re: Arquitectura P2P entre servidores
El 13 de diciembre de 2010 12:05, Julian Reyes Escrigas julian.reyes.escri...@gmail.com escribió: Ricardo te has confundido te explico en el mail inicial escribi que una vez al mes el servidor central va a tener una confrontacion de la informacion de la base de datos con la base ded atos de otros sistemas pero aparte de eso los usuarios van a alimentar los servidores secundarios que estos deben a su vez alimentar el principal, es logico que la informacion de los servidores secundarios deben llegar en algun momento al principal de esto debe ser lo mas pronto posible hay una expresion llamada aplicar poder de sintesis que hubiera sido bueno aplicar en tu thread... ;) creo que una solucion simple y que no requiera configurar/implementar replicacion de MySQL o Postgres seria, y tal como ya lo mencionaron, el uso de webservices (mediante HTTPS). SOAP o REST da casi lo mismo si el servidor y los clientes los implementaras tu mismo usando el mismo lenguaje (PHP). -- Ricardo Mun~oz A. http://www.tux.cl
Re: Arquitectura P2P entre servidores
En vez de pensar en cocinar cosas... ¿no será mejor probar alguna de estas?: http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas No he probado nunca algo así, pero suena como una solución a este problema. -- ~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~ http://card.ly/gon http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
Re: Arquitectura P2P entre servidores
Gonzalo He leido las soluciones basadas en sistema de base de datos distrbuidas y no pienso que sea la solución a pesar de que los servidores tienen en comun datos se necesitan realizar datos que sean a ser tratados con PHP por lo que no intersa como solución la comunica directa de las bases de datos sino mas bien la comunicación entre las aplicaciones de una manera que se garantice que en algún momento la información va a ser transferida, sea en el momento de ingreso o luego cuando exista conexión. On lunes 13 de diciembre de 2010 at 11:16, Gonzalo Diaz Cruz wrote: En vez de pensar en cocinar cosas... ¿no será mejor probar alguna de estas?: http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas No he probado nunca algo así, pero suena como una solución a este problema. -- ~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~ http://card.ly/gon http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
