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
