[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problema con mysql cluster



El 2012-05-22 00:30, Maykel Franco Hernández escribió:

El 2012-05-21 22:15, Marc Aymerich escribió:

2012/5/20 Matías Bellone <matiasbellone@gmail.com>:
2012/5/20 Maykel Franco Hernández <maykel@maykel.sytes.net>:
El 2012-05-19 22:57, Matías Bellone escribió: 2012/5/19 Maykel Franco Hernández <maykel@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.
Pero si lo dice en el texto que has pasado, no?

In general, setting MAX_ROWS to twice the number of rows that you
expect to store in the table should be sufficient.

-- 
Marc


-- To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: [🔎] CA+DCN_v05YoqpizqQAXMPkz8W+5qT_gs_K+-RpTnm5N8aXv1CA@mail.gmail.com">http://lists.debian.org/[🔎] CA+DCN_v05YoqpizqQAXMPkz8W+5qT_gs_K+-RpTnm5N8aXv1CA@mail.gmail.com 


Si lo que dice es que tengo que crear el doble del número de filas totales de la tabla y que con eso debería solventarse. Pero claro la tengo en ndbcluster, tendré que hacer un replace cambiándola de ndbcluster a InnoDB por ejemplo, hacer un SELECT COUNT(*) FROM "tabla";
 
Luego una vez importada, le definiré el MAX_ROWS al doble para esa tabla y finalmente le haré un alter table , para pasarla de InnoDB a ndbcluster.
 
Lo probaré.
 
Saludos y gracias.
 
 
 
 
 

 

 

Hola muy buenas, sigo con este tema porque me tiene un poco loco....

 

He realizado lo siguiente:

 

Al importar la tabla "table" como InnoDB todo OK. El problema al pasarlo a ndbcluster como engine, por defecto va realizando las grabaciones en memoria ram.

Siguiendo varios hilos en los foros, hay muchísima gente que ha tenido el mismo problema que nos da a nosotros y la respuesta por parte de mysql que han tenido han sido bugs, bugs, actualiza a la version...Y es que tenemos la última versión tanto de mysql como servicio como el mysql cluster ndb.

ndb_mgm> show
Cluster Configuration
---------------------
[ndbd(NDB)]    2 node(s)
id=2    @10.100.100.157  (mysql-5.5.20 ndb-7.2.5, Nodegroup: 0, Master)
id=3    @10.100.100.158  (mysql-5.5.20 ndb-7.2.5, Nodegroup: 0)

[ndb_mgmd(MGM)]    1 node(s)
id=1    @10.100.100.159  (mysql-5.5.20 ndb-7.2.5)

[mysqld(API)]    4 node(s)
id=4    @10.100.100.157  (mysql-5.5.20 ndb-7.2.5)
id=5    @10.100.100.158  (mysql-5.5.20 ndb-7.2.5)
id=6 (not connected, accepting connect from any host)
id=7 (not connected, accepting connect from any host)


Buscando documentación de cómo pasar esos datos al disco duro en vez de en memoria, encontré esto:

http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-disk-data-objects.html

He definido lo siguiente:

CREATE LOGFILE GROUP lg_1
    ADD UNDOFILE 'undo_1.log'
    INITIAL_SIZE 100000M
    UNDO_BUFFER_SIZE 2M
    ENGINE NDBCLUSTER;


CREATE TABLESPACE ts_1
    ADD DATAFILE 'data_1.dat'
    USE LOGFILE GROUP lg_1
    INITIAL_SIZE 100000M
    ENGINE NDBCLUSTER;


Le puesto 100G porque he probado ya con 10G, 20G y siempre suelta el mismo error al ejecutar el comando:

ALTER TABLE statsMobileBrowsing_ TABLESPACE ts_1 STORAGE DISK ENGINE NDBCLUSTER;

Se queda ejecutándose durante 2 horas y luego pega el pete. Este comando lo que hace en "teoría" es definirse como unos temporales(objects) para almacenarlo en el disco:

root@msyql2-cluster:/usr/local/mysql/data/ndb_3_fs# du -hs *
848K    D1
4.7G    D10
161M    D11
848K    D2
161M    D8
161M    D9
248K    LCP
98G    data_1.dat
98G    undo_1.log


Y ahí aparecen los dos archivos que he definido. Se define primero un grupo de log y luego el tablespace que es donde se guarda los datos. Me pega este error:

mysql> use statsMobileBrowsing;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> ALTER TABLE statsMobileBrowsing_ TABLESPACE ts_1 STORAGE DISK ENGINE NDBCLUSTER;
ERROR 1114 (HY000): The table '#sql-5fd_6bc4' is full


La verdad es que me tiene un poco desesperado, porque aparte de que lo estoy haciendo tal cual lo pone en la página, como el procedimiento tarda mucho en ejecutarse, se pierde bastante tiempo.

 

Alguien ha conseguido solucionar este error en mysql??



Saludos y gracias por anticipado.

 

Reply to: