Ricardo Mun~oz A. escribió: > Alvaro Herrera wrote: >>> "Slony-I is a system intended for data centers and backup sites, where >>> the normal mode of operation is that all nodes are available all the >>> time, and where all nodes can be secured. If you have nodes that are >>> likely to regularly drop onto and off of the network, or have nodes that >>> cannot be kept secure, Slony-I is probably not the ideal replication >>> solution for you." >> >> Esto no es lo mismo que tener conexiones de baja velocidad. Por lo >> demas, qué tan problematico sea depende del volumen de transacciones que >> tengas. > > cierto. en el peor de los casos (si se corta el enlace entre la of.central > y las sucursales) hay algo que se puede hacer a nivel de RDBMS?
Bueno, lo que hace Slony-I es dejar una cola de operaciones en el maestro, que se va vaciando a medida que los esclavos las reciben y aplican. Si se cae la conexion, la cola empieza a crecer hasta que la conexion vuelve. En realidad ese es el modelo de operacion normal de Slony-I: todas las operaciones pasan siempre por una cola. Lo que pasa en condiciones normales es que la cola se transmite en forma "instantanea". -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "Pido que me den el Nobel por razones humanitarias" (Nicanor Parra) From [EMAIL PROTECTED] Mon Sep 24 12:35:45 2007 From: [EMAIL PROTECTED] (Ricardo Mun~oz A.) Date: Mon Sep 24 12:41:47 2007 Subject: desarrollo deaAplicacion grande In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Alvaro Herrera wrote: > Ricardo Mun~oz A. escribió: > >> Alvaro Herrera wrote: >> > > >>>> "Slony-I is a system intended for data centers and backup sites, where >>>> the normal mode of operation is that all nodes are available all the >>>> time, and where all nodes can be secured. If you have nodes that are >>>> likely to regularly drop onto and off of the network, or have nodes that >>>> cannot be kept secure, Slony-I is probably not the ideal replication >>>> solution for you." >>>> >>> Esto no es lo mismo que tener conexiones de baja velocidad. Por lo >>> demas, qué tan problematico sea depende del volumen de transacciones que >>> tengas. >>> >> cierto. en el peor de los casos (si se corta el enlace entre la of.central >> y las sucursales) hay algo que se puede hacer a nivel de RDBMS? >> > > Bueno, lo que hace Slony-I es dejar una cola de operaciones en el > maestro, que se va vaciando a medida que los esclavos las reciben y > aplican. Si se cae la conexion, la cola empieza a crecer hasta que la > conexion vuelve. > > En realidad ese es el modelo de operacion normal de Slony-I: todas las > operaciones pasan siempre por una cola. Lo que pasa en condiciones > normales es que la cola se transmite en forma "instantanea". > claro, por lo mismo si hay operaciones encoladas que modifican datos en la BD de una sucursal sin enlace, y esos mismos datos fueron modificados en la BD "central" podria quedar la c*!#$... -- Ricardo Mun~oz A. Usuario Linux #182825 (counter.li.org) From [EMAIL PROTECTED] Mon Sep 24 12:52:41 2007 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Mon Sep 24 12:55:08 2007 Subject: desarrollo deaAplicacion grande In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Ricardo Mun~oz A. escribió: > Alvaro Herrera wrote: >> Bueno, lo que hace Slony-I es dejar una cola de operaciones en el >> maestro, que se va vaciando a medida que los esclavos las reciben y >> aplican. Si se cae la conexion, la cola empieza a crecer hasta que la >> conexion vuelve. >> >> En realidad ese es el modelo de operacion normal de Slony-I: todas las >> operaciones pasan siempre por una cola. Lo que pasa en condiciones >> normales es que la cola se transmite en forma "instantanea". > > claro, por lo mismo si hay operaciones encoladas que modifican datos en la > BD de una sucursal sin enlace, y esos mismos datos fueron modificados en la > BD "central" podria quedar la c*!#$... No, porque el central no puede modificar tablas para las que la sucursal es maestra, y viceversa. Es por ese motivo que Slony-I es maestro-esclavo y no multimaestro: no hay manejo de conflictos. Hay soluciones multimaestro como Postgres-R: http://postgres-r.org/ pero es un problema muchisimo mas complejo de lo que parece; por ej. MySQL Cluster tiene limitaciones y problemas que cuando las miras te das cuenta de lo absurdas que son y de lo limitado de los casos en que se pueden aplicar. Las soluciones comerciales como Oracle RAC tambien tienen limitaciones super raras que obviamente no te cuentan en los folletos de marketing. La unica diferencia entre las soluciones de replicacion de Postgres versus otros gestores de BDs es que Postgres es honesto respecto de las limitaciones. Los desarrolladores de Postgres no estan interesados en soluciones parciales que funcionan la mitad del tiempo; si quieres cosas asi, puedes hacerlas perfectamente tu mismo. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "Ciencias políticas es la ciencia de entender por qué los políticos actúan como lo hacen" (netfunny.com) From [EMAIL PROTECTED] Mon Sep 24 13:18:34 2007 From: [EMAIL PROTECTED] (Ricardo Mun~oz A.) Date: Mon Sep 24 13:21:38 2007 Subject: Evitar sql injection y xss In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Raul Perez wrote: > Salud a todos > > Tengo mysql 5 y phpp 5 en un servidor con centos > La pregunta es que codigo han implementado ustedes para > asegurar sus aplicaciones en php para evitar injection de sql y xss migrar a CakePHP y usar las herramientas que provee, mas info en [1]... ;) en todo caso, en el mismo Cake la validacion de "SQL injection" viene "de fabrica"... por ejemplo en el metodo findAll(), y en todos los otros metodos que sirven para que el framework traiga datos desde la BD, se puede hacer esto: ... $condiciones = array('nombres' => "LIKE %$nombres%", 'otro_campo' => "<> $valor", etc.); $this->set('clientes', $this->Cliente->findAll($condiciones)); ... entonces, en findAll() el framework va armar el correspondiente SELECT y validara automaticamente todas las condiciones en el arreglo $condiciones evitando SQL injection, independientemente del motor de BD que uses con el framework. [1] http://www.scribd.com/doc/5546/CakePHP-tutorial-no-3-from-IBM -- Ricardo Mun~oz A. Usuario Linux #182825 (counter.li.org) From [EMAIL PROTECTED] Mon Sep 24 13:55:28 2007 From: [EMAIL PROTECTED] (Ricardo Mun~oz A.) Date: Mon Sep 24 13:58:31 2007 Subject: desarrollo deaAplicacion grande In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]><[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Alvaro Herrera wrote: > Ricardo Mun~oz A. escribió: > >> Alvaro Herrera wrote: >> > > >>> Bueno, lo que hace Slony-I es dejar una cola de operaciones en el >>> maestro, que se va vaciando a medida que los esclavos las reciben y >>> aplican. Si se cae la conexion, la cola empieza a crecer hasta que la >>> conexion vuelve. >>> >>> En realidad ese es el modelo de operacion normal de Slony-I: todas las >>> operaciones pasan siempre por una cola. Lo que pasa en condiciones >>> normales es que la cola se transmite en forma "instantanea". >>> >> claro, por lo mismo si hay operaciones encoladas que modifican datos en la >> BD de una sucursal sin enlace, y esos mismos datos fueron modificados en la >> BD "central" podria quedar la c*!#$... >> > > No, porque el central no puede modificar tablas para las que la sucursal > es maestra, y viceversa. > cierto. pero depende del modelo y la aplicacion si es que en algun momento se puede producir un conflicto... por algo los mismos desarrolladores de Slony-I indican que sirve cuando todos los nodos estan disponibles todo el tiempo... > Es por ese motivo que Slony-I es maestro-esclavo y no multimaestro: no > hay manejo de conflictos. > > Hay soluciones multimaestro como Postgres-R: http://postgres-r.org/ pero > es un problema muchisimo mas complejo de lo que parece; por ej. MySQL > Cluster tiene limitaciones y problemas que cuando las miras te das > cuenta de lo absurdas que son y de lo limitado de los casos en que se > pueden aplicar. Las soluciones comerciales como Oracle RAC tambien > tienen limitaciones super raras que obviamente no te cuentan en los > folletos de marketing. > > La unica diferencia entre las soluciones de replicacion de Postgres > versus otros gestores de BDs es que Postgres es honesto respecto de las > limitaciones. Los desarrolladores de Postgres no estan interesados en > soluciones parciales que funcionan la mitad del tiempo; si quieres cosas > asi, puedes hacerlas perfectamente tu mismo. > volviendo al mail original, le recomendarias a Graciela el uso de Postgres + Slony-I? -- Ricardo Mun~oz A. Usuario Linux #182825 (counter.li.org) From [EMAIL PROTECTED] Mon Sep 24 14:08:56 2007 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Mon Sep 24 14:11:30 2007 Subject: desarrollo deaAplicacion grande In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Ricardo Mun~oz A. escribió: > Alvaro Herrera wrote: >> Ricardo Mun~oz A. escribió: >> >>> Alvaro Herrera wrote: >>> >> >> >>>> Bueno, lo que hace Slony-I es dejar una cola de operaciones en el >>>> maestro, que se va vaciando a medida que los esclavos las reciben y >>>> aplican. Si se cae la conexion, la cola empieza a crecer hasta que la >>>> conexion vuelve. >>>> >>>> En realidad ese es el modelo de operacion normal de Slony-I: todas las >>>> operaciones pasan siempre por una cola. Lo que pasa en condiciones >>>> normales es que la cola se transmite en forma "instantanea". >>>> >>> claro, por lo mismo si hay operaciones encoladas que modifican datos en >>> la BD de una sucursal sin enlace, y esos mismos datos fueron modificados >>> en la BD "central" podria quedar la c*!#$... >>> >> >> No, porque el central no puede modificar tablas para las que la sucursal >> es maestra, y viceversa. > > cierto. pero depende del modelo y la aplicacion si es que en algun momento > se puede producir un conflicto... por algo los mismos desarrolladores de > Slony-I indican que sirve cuando todos los nodos estan disponibles todo el > tiempo... Estas confundiendo una limitacion de arquitectura con una recomendación. Slony-I funciona sin problemas cuando hay fallas de red, aunque la cola de eventos va a ocupar espacio en disco. Pero eso es totalmente independiente de una hipotetica resolucion de conflictos, que no existe porque es innecesaria. Es innecesaria debido a que Slony-I es una solucion maestro-esclavo, por lo tanto es imposible que existan conflictos debido a que un servidor esclavo no puede escribir en la tabla para la cual es esclavo. > volviendo al mail original, le recomendarias a Graciela el uso de Postgres > + Slony-I? Depende mucho de la naturaleza de la aplicacion. Lo que yo intentaria hacer seria tener copias esclavas de la base de dato en cada una de las sucursales, de solo lectura (con Slony-I); y que las escrituras vayan a la base de datos central. De este modo no se notaria la lentitud del enlace en las consultas de solo lectura (puesto que son locales a la sucursal), y se requeriria contactar al central solamente para las escrituras. De esa forma, te ahorras todo el problema de la resolucion de conflictos y de replicacion multimaestro. El inconveniente es que cuando se caiga la conexion sucursal-servidor, no podrias escribir (pero ojo, que eso sucede en casi todos los sistemas multimaestro, incluso los comerciales). -- Alvaro Herrera http://www.advogato.org/person/alvherre "On the other flipper, one wrong move and we're Fatal Exceptions" (T.U.X.: Term Unit X - http://www.thelinuxreview.com/TUX/) From [EMAIL PROTECTED] Mon Sep 24 15:45:49 2007 From: [EMAIL PROTECTED] (Rodrigo Fuentealba) Date: Mon Sep 24 15:48:14 2007 Subject: desarrollo deaAplicacion grande In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El 24/09/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió: > Ricardo Mun~oz A. escribió: > > cierto. pero depende del modelo y la aplicacion si es que en algun momento > > se puede producir un conflicto... por algo los mismos desarrolladores de > > Slony-I indican que sirve cuando todos los nodos estan disponibles todo el > > tiempo... > Estás poniendo a Slony-I para que se adapte a tu modelo, cuando en realidad es al revés, debes adaptar tu modelo para que funcione con esta solución. Por eso es que Álvaro hablaba de tablas heredadas; por lo que entiendo, y como se me ocurre usarla, es hacer una tabla maestra en cada zona que "extienda" a la tabla de datos total, utilizando la característica de orientación a objetos de PostgreSQL, y a esa tabla que extiende la pones como maestra en la aplicación. ¿Es así, Álvaro? > > volviendo al mail original, le recomendarias a Graciela el uso de Postgres > > + Slony-I? > > Depende mucho de la naturaleza de la aplicacion. También lo creo así. > Lo que yo intentaria > hacer seria tener copias esclavas de la base de dato en cada una de las > sucursales, de solo lectura (con Slony-I); y que las escrituras vayan a > la base de datos central. De este modo no se notaria la lentitud del > enlace en las consultas de solo lectura (puesto que son locales a la > sucursal), y se requeriria contactar al central solamente para las > escrituras. Mira, este plugin lo estamos arreglando y usando para un sitio Web en el cual tenemos ese inconveniente a nivel nacional, y no ha tenido mayor problema hasta ahora (aunque es alfa!): http://trac.symfony-project.com/trac/wiki/sfPropelLoadbalancerPlugin El problema podría ser si la aplicación escribe constantemente en la base de datos y volúmenes grandes de información va a ser un problema grande; hay que dimensionar en este aspecto. Por poner un ejemplo descabellado (pero posible!!!), si se les ocurre la brillante idea de meter en la base de datos algunos archivos de una cierta cantidad de Mb. para que éstos se compartan entre todas las sucursales van a tener un problema así. Para eso es mejor utilizar un repositorio local o alguna otra solución independiente de la base de datos. Por alguno de estos parajes utilizaban un manejador de documentos (no relacionado con PostgreSQL) con una conexión de 2 Mb. fijos, y era un problema cuando alguien intentaba acceder a un documento grande desde otra sucursal. > De esa forma, te ahorras todo el problema de la resolucion de conflictos > y de replicacion multimaestro. El inconveniente es que cuando se caiga > la conexion sucursal-servidor, no podrias escribir (pero ojo, que eso > sucede en casi todos los sistemas multimaestro, incluso los > comerciales). Inclusive aquí debes apelar a las leyes de la física y no aceptar a personas que se crean Criss Angel, para que aparezcan al mismo tiempo en dos sucursales distintas solicitando la misma información. Entrete caso, :-s -- Rodrigo Fuentealba
