2012/5/20 Maykel Franco Hernández <may...@maykel.sytes.net>:
> El 2012-05-20 21:16, Matías Bellone escribió:
>
> 2012/5/20 Maykel Franco Hernández <may...@maykel.sytes.net>:
>
> El 2012-05-19 22:57, Matías Bellone escribió: 2012/5/19 Maykel Franco
> Hernández <may...@maykel.sytes.net>: Hola muy buenas, he implementado mysql
> cluster en debian lenny y la verdad es que va bastante bien. Estoy tratando
> de importar una bbdd que es bastante grande, ocupa 16 GB. Al hacer un: mysql
> -u root -p "database" < mysql.sql Me reporta el siguiente error: Table is
> full... He estado mirando desde el cliente management de administración
> ejecutando este comando: ALL REPORT MEMORY USAGE Y se ve como poco a poco va
> subiendo el index y el data: ndb_mgm> ALL REPORT MEMORY USAGE Node 2: Data
> usage is 80%(63 32K pages of total 8192) Node 2: Index usage is 7%(60 8K
> pages of total 8224) Node 3: Data usage is 81%(63 32K pages of total 8192)
> Node 3: Index usage is 7%(60 8K pages of total 8224) Eso aparentemente te
> dice la cantidad de páginas que tiene, no la cantidad de memoria utilizada.
> Cuando llega ya cerca del 91% se cae la importación del sql y devuelve:
> ERROR 1114 (HY000) at line 227: The table 'table_log' is full He estado
> mirando en la documentación de mysql y dice que el mysql cluster soporta
> comom áximo 8192MB de Data Memory. Depende de la versión, por lo que dice el
> manual de MySQL 5.0[1] tanto DataMemory como IndexMemory pueden ser entre
> 1Mb y 1Tb [1]
> http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-datamemory
> He probado a subirle el IndexMemory y el DataMemory a por ejemplo 16000 pero
> sigue con el mismo error. Es más, al ejecutarle el "ALL REPORT MEMORY USAGE"
> sigue teniendo 8192. Estás leyendo mal los números reportados. Creo que la
> siguiente aclaración del manual podría ser lo que ocurre en tu caso:
> Currently, MySQL Cluster can use a maximum of 512 MB for hash indexes per
> partition, which means in some cases it is possible to get Table is full
> errors in MySQL client applications even when ndb_mgm -e "ALL REPORT
> MEMORYUSAGE" shows significant free DataMemory. This can also pose a problem
> with data node restarts on nodes that are heavily loaded with data. You can
> force NDB to create extra partitions for MySQL Cluster tables and thus have
> more memory available for hash indexes by using the MAX_ROWS option for
> CREATE TABLE. In general, setting MAX_ROWS to twice the number of rows that
> you expect to store in the table should be sufficient. Eso quiere decir que
> si tenés demasiadas filas en una sola partición con índices de ese tipo,
> estás llegando a ese límite. Y no podría aumentar ése limite??
>
> Si la documentación no indica qué directiva de configuración sirve
> para modificar esos límites probablemente quiera decir que la única
> forma de cambiar esos valores sea modificando el código de MySQL y
> re-compilando.
>
> Probablemente preguntando en una lista de discusión específica de
> MySQL tengas más suerte.
>
>
> Vale muchas gracias, no obstante tiene que ser una restricción del motor
> ndbcluster, porque si transformo esas tablas de la bbdd a innodb y la
> importo todo OK, pero si la transformo a ndbcluster como motor, me pega ése
> error...No me bastaría con modificar el indexmemory o el datamemory???
>

Si lees el enlace que te pasé, es precisamente una limitación de
ndbcluster y la aclaración de dichos límites es parte de la
explicación de las directivas DataMemory e IndexMemory así que, como
ya dije antes: probablemente la única forma de modificar esos límites
sea modificando el código de MySQL y re-compilando. Ahora, como
programador, estoy seguro que hay muy buenas razones para la
existencia de dichos límites.

Saludos,
Toote

PD: evita el HTML
-- 
Web: http://www.enespanol.com.ar


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANk6MLY9_QA=knqa-wrrcd2q2b_9n3cpxgxgxwt9x9y7o14...@mail.gmail.com

Responder a