• O ExecuteOnComputer o HostName.

• El parámetro NoOfReplicas

• [NBDB]Id

  Este es el ID del nodo usado como dirección del nodo para todos los mensajes internos del cluster. Este es un entero entre 1 y 63. Cada nodo en el cluster tiene una identidad única.

• [NDBD]ExecuteOnComputer

  Se refiere a uno de las máquinas (equipos) definidos en la sección COMPUTER .

• [NDBD]HostName

  Especificar este parámetro tiene un efecto similar a especificar ExecuteOnComputer. Define el nombre de equipo de la máquina en que reside el nodo de almacenamiento. Este parámetro o ExecuteOnComputer es necesario para especificar un nombre de equipo distinto a localhost.

• (OBSOLETO) [NDBD]ServerPort

  Cada nodo en el cluster usa un puerto para conectarse a otros nodos. Este puerto se usa también para transporte distinto a TCP en la fase de establecimiento de la conexión. Ahora, el puerto por defecto se reserva dinámicamente de forma que se asegura que dos nodos en la misma máquina reciban el mismo número de puerto, no debe ser necesario indicar un valor para este parámetro.

• [NDBD]NoOfReplicas

  Este parámetro global sólo puede cambiarse en la sección [NDBD DEFAULT] , y define el número de replicas para cada tabla almacenada en el cluster. Este parámetro también especifica el tamaño de los grupos de nodos. Un grupo de nodos es un conjunto de nodos que almacenan todos la misma información.

  Los grupos de nodos se forman implítamente. El primer grupo de nodos se forma por el conjunto de nodos de datos con los IDs de nodo más bajos, el siguiente grupo de nodos se conforma con el conjunto del siguiente conjunto de identidades de nodos más baja, y así. Como ejemplo, asuma que tenemos 4 nodos de datos y que NoOfReplicas es 2. Los cuatro nodos de datos tienen los IDs 2, 3, 4 y 5. El primer grupo de nodos está formado con los nodos 2 y 3, y el segundo grupo con los nodos 4 y 5. Es importante configurar el cluster de forma que los nodos en el mismo grupo no se guarden en la misma máquina, ya que en esta situación un fallo de hardware haría que fallare el cluster entero.

  Si no hay IDs de nodos el orden de los nodos de datos es el factor determinante para el grupo de nodos. Se haga o no una asignación explícita, puede verse en la salida del comando del cliente administrador SHOW .

  No hay valor por defecto para NoOfReplicas; el valor máximo posible es 4.

• [NDBD]DataDir

  Este parámetro especifica el directorio donde los ficheros de traceo, ficheros de log, ficheros pid y logs de errores se guardan.

• [NDBD]FileSystemPath

  Este parámetro especifica el directorio donde se guardan todos los ficheros para metadatos, logs de REDO, logs de UNDO y ficheros de datos. Por defecto es el directorio especificado por DataDir. Nota: Este directorio debe existir antes de inciar el proceso ndbd.

  La jerarquía de directorio recomendada para MySQL Cluster incluye /var/lib/mysql-cluster, bajo qué directorio se crea un sistema de ficheros de un nodo. Este subdirectorio contiene el ID del nodo. Por ejemplo, si el ID del nodo es 2, el subdirectorio se llama ndb_2_fs.

• [NDBD]BackupDataDir

  Es posible especificar el directorio en que se guardan las copias de seguridad. Por defecto, este directorio es FileSystemPath/BACKUP. (Consulte secciones anteriores.)

• [NDBD]DataMemory

  Este parámetro define la cantidad de espacio disponible para almacenar registros de base de datos. La cantidad entera se guardará en memoria, así que es extremadamente importante que la máquina tenga sufuciente memoria física para guardar este valor.

  La memoria reservada por DataMemory se usa para almacenar los registros y los índices. Cada registro tiene una longitud fija . (Incluso columnas VARCHAR se almacenan como columnas de longitud fija.) Hay una sobrecarga de 16-byte para cada registro; una cantidad adicional para cada registro se necesita porque se almacena en páginas de 32KB con sobrecarga de 128 byte por página (consulte a continuación). También hay una pequeña cantidad gastada por página debido al hecho que cada registro se almacena en sólo una página. El tamaño de registro máximo actualmente es de 8052 bytes.

  El espacio de memoria definido por DataMemory se usa para almacenar índices ordenados, que usa acerca de 10 bytes por registor. Cada registro de tabla se representa en el índice ordenado. Un error común entre usuarios es asumir que todos los índices se almacenan en la memoria reservada por IndexMemory, pero no es así: sólo claves primarias e índices hash únicos usan esta memoria; los índices ordenados usan la memoria almacenada por DataMemory. Sin embargo, crear una clave primar única o índice hash único también crea un índice ordenado en la misma clave, a no ser que especifique USING HASH en el comando de creación del índice. Esto puede verificarse ejecutando ndb_desc -d db_name table_name en el cliente de administración.

  El espacio de memoria reservado por DataMemory consiste en 32KB páginas, que se reservan en fragmentos de tabla. Cada tabla se particiona normalmente en el mismo número de fragmentos como hay nodos de datos en el cluster. Por lo tanto, por cada nodo, hay el mismo número de fragmentos así como se especifica en NoOfReplicas. Una vez que una página se ha reservado, no es posible retornarla al pool de páginas libres, excepto borrando la tabla. Ejecutar el modo de recuperación también comprime la partición ya que todos los registros se insertan en particiones vacías por parte de los otros nodos vivos.

  El espacio de memoria DataMemory también contiene información UNDO: Para cada actualización, se reserva una copia de los registros no alterados en DataMemory. También hay una referencia de cada copia en los índices de tablas ordenadas. Los índices hash únicos se modifican sólo cuando las columnas de índice único se actualizan, en tal caso se inserta una nueva entrada en la tabla de índices y la antigua entrada se borra al hacer un commit. Por esta razón, es necesario reservar espacio necesario para tratar la transacción más grande realizada por aplicaciones usando el cluster. En cualquier caso, realizar unas cuantas transacciones muy grandes no tiene ventaja sobre usar muchas pequeñas, por las siguientes razones:

  • Las transacciones grandes no son más rápidas que las pequeñas.

  • Las transacciones grandes incrementan el número de operaciones que se pierden y deben repetirse en caso de fallo de transacción

  • Las transacciones grandes usan más memorias

  El valor por defecto de DataMemory es 80MB; el mínimo es 1MB. No hay tamaño máximo, pero en realidad el tamaño máximo tiene que adaptarse para que el proceso no empiece ha hacer swapping cuando llega al límite. Este límite se determina por la cantidad de RAM física disponible en la máquina y por la cantidad de memoria que el sistema operativo puede asignar a un proceso. Sistemas operativos 32-bit están normalmente limitados a 2-4GB por proceso; los sistemas opertivos de 64-bit pueden usar más. Para bases de datos grandes, puede ser preferible usar un sistema operativo 64-bit por esta razón. Además, es posible ejecutar más de un proceso ndbd por máquina, y esto puede ser ventajoso en máquinas con múltiples CPUs.

• [NDBD]IndexMemory

  Este parámetro controla la cantidad de almacenamiento usado por índices hash en MySQL Cluster. Los índices hash siempre son usados por índices de clave primaria, índices únicos y restricciones únicas. Tenga en cuenta que cuando define una clave primaria y un índice único, se crean dos índices, uno de los cuales es un índice hash usado por todos los accesos a tuplas así como tratamiento de bloqueos. También se usa para forzar restricciones únicas.

  El tamaño del índice hash es de 25 bytes por registro, más el tamaño de la clave primaria. Para claves primarias mayores a 32 bytes se añaden otros 8 bytes .

  Considere una tabla definida por

  CREATE TABLE example
  (
    a INT NOT NULL,
    b INT NOT NULL,
    c INT NOT NULL,
    PRIMARY KEY(a),
    UNIQUE(b)
  ) ENGINE=NDBCLUSTER;
  

  Hay una sobrecarga de 12 bytes (tener columnas no nulas ahorra 4 bytes de sobrecarga) más 12 bytes de datos por registro. Además tenemos dos índices ordenados en las columnas a y b consumiendo cerca de 10 bytes cada uno por registro. Hay un índice hash de clave primaria en la tabla base con unos 29 bytes por registro. La restricción única se implementa por tablas separadas con b como clave primaria y a como columna. Esta tabla consumirá otros 29 bytes de memoria de índice por registro en la tabla ejemplo así como 12 bytes de sobrecarga, más 8 bytes de datos de registros.

  Así, para un millón de registros, necesitamos 58 MB para memoria de índices para tratar los índices hash para la clave primaria y la restricción única. También necesitamos 64 MB para los registros de la tabla base y la tabla de índice único, más las dos tablas con índice ordenado.

  Puede ver que los índices hash tienen una buena cantidad de espacio de memoria; sin embargo, proporcionan acceso muy rápido a los datos retornados. También se usan en MySQL Cluster para tratar restricciones únicas.

  Actualmente el único algoritmo de partición es hashing y los índices ordenados son locales para cada nodo. Por lo tanto los índices ordenados no pueden usarse para tratar restricciones únicas en caso general.

  Un punto importante paraIndexMemory y DataMemory es que el tamaño de base de datos total es la suma de toda la memoria de datos y toda la memoria de índice para cada grupo de nodos. Cada grupo de nodos se usa para guardar información replicada, así que si hay cuatro nodos con 2 réplicas, habrá dos nodos de grupos. Por lo tanto, la cantidad total de memoria disponible es 2*DataMemory para cada nodo de datos.

  Se recomienda que DataMemory y IndexMemory se inicialice con el mismo valor para todos los nodos. Desde que los datos se distribuyen eventualmente sobre todos los nodos en el cluster la cantidad de espacio máxima disponible no es mejor que la del menor nodo del cluster.

  DataMemory y IndexMemory pueden cambiarse, pero decrementar cualquiera de ellos puede ser arriesgado; al hacerlo puede hacer que un nodo o incluso el cluster entero no sea capaz de reiniciar debido a que hay memoria insuficiente. Incrementar estos valores está bien, pero se recomienda que estas actualizaciones se realicen de la misma manera que una actualización de software, comenzando con una actualización del fichero de configuración, y luego reiniciando el servidor de administración seguido del reinicio de cada nodo de datos.

  Las actualizaciones no incrementan la cantidad de memoria índice usada. Las inserciones tienen efecto inmediatamente; sin embargo, los registros no se borran realmente hasta que la transacción hace un commit.

  El valor por defecto para IndexMemory es 18MB. El mínimo es 1MB.

• [NDBD]MaxNoOfConcurrentTransactions

  Para cada transacción activa en el cluster debe haber un registro en uno de los nodos del cluster. La tarea de coordinar transacciones se envía entre los nodos: el número total de registros de transacciones en el cluster es el número de transacciones en cualquier nodo por el número de nodos en el cluster.

  Los registros de transacciones se guardan en servidores MySQL individuales. Normalmente al menos hay un registro de transacción por conexión que usa cualquier tabla en el cluster. Por esta razón, debe asegurarse que hay más registros de transacciones en el cluster que conexiones concurrentes en todos los servidores MySQL del cluster.

  Este parámetro debe inicializarse al mismo valor para todos los nodos del cluster.

  Cambiar este parámetro nunca es seguro y puede causar que un cluster falle. Cuando un nodo falla uno de los nodos (el nodo superviviente más antiguo) levanta el estado de transacción de todas las transacciones que haya en funcionamiento en todos los nodos que han fallado cuando ha ocurrido el fallo. Por lo tanto es importante que este nodo tenga tantos registros de transacción como el nodo que ha fallado.

  El valor por defecto para este parámetro es 4096.

• [NDBD]MaxNoOfConcurrentOperations

  Es una buena idea ajustar el valor de este parámetro según el tamaño y número de transacciones. Cuando se realizan transacciones de sólo unas cuantas operaciones y que no involucren muchos registros, no hay necesidad de inicializar este parámetro con un valor muy alto. Cuando realiza transacciones grandes involucrando muchos registros necesita cambiar a un valor mayor este parámetro.

  Los registros se mantienen para cada transacción que actualice los datos del cluster, tanto en el coordinador de la transacción como en los nodos donde se hacen las actualizaciones. Estos registros contienen información de estado necesaria para encontrar registros UNDO para deshacer cambios, bloquear colas y otros propósitos.

  Este parámetro debe inicializarse al número de registros a actualizar simultáneamente en transacciones, dividido por el número de nodos de datos del cluster. Por ejemplo, en un cluster que tenga 4 nodos de datos y del que se espera que trate 1,000,000 de actualizaciones concurrentes usando transacciones debe inicializar este valor a 1000000 / 4 = 250000.

  Leer consultas que hacen bloqueos hace que se creen registros. Se reserva un espacio extra en los nodos individuales para los casos en que la distibución no es perfecta entre los nodos.

  Cuando las consultas usan el índice hash único, hay dos registros de operación usados para registrar la transacción. El primer registro representa la lectura en la tabla índice y el segundo trata la operación en la tabla base.

  El valor por defecto para este parámetro es 32768.

  Este parámetro trata dos valores que se pueden configurar separadamente. El primero de ellos especifica cuántos registros de operación se tienen que situar en el coordinador de la transacción. La segunda parte especifica cuántos registros de operación serán locales en la base de datos.

  Una transacción muy grande realizada en un cluster de 8 nodos requiere tantos registros de operación en el coordinador de transacción como lecturas, actualizaciones y operaciones de borrado involucradas en la transacción. Sin embargo, los registros de operación se envían a los 8 nodos. Por lo tanto, si es necesario configurar el sistema para una transacción muy grande, es buena idea configurar las dos partes por separado. MaxNoOfConcurrentOperations se usará siempre para calcular el número de registros de operación en la porción del coordinador de transacción del nodo.

  Es importante tener una idea de los requerimientos de memoria para registros de operaciones. Actualmente es aproximadamente 1KB por registro.

• [NDBD]MaxNoOfLocalOperations

  Por defecto, este parámetro se calcula como 1.1 * MaxNoOfConcurrentOperations que encaja en sistemas con muchas transacciones simultáneas, ninguna de ellas demasiado grande. Si hay una necesidad de tratar una transacción muy grande de golpe y hay muchos nodos, es buena idea sobreescribir el valor por defecto especificando explícitamente este parámetro.

• [NDBD]MaxNoOfConcurrentIndexOperations

  Para consultas usando un índice hash único, el conjunto temporal de registros de operaciones se usa durante la fase de ejecución de una consulta. Este parámetro delimita el tamaño del conjunto de registros. Así este registro sólo se reserva mientras se ejecuta una parte de una consulta, en cuanto ha acabado la ejecución se libera el registro. El estado necesario para tratar abortos y commits se trata mediante los registros operacionales normales donde el tamaño del pool se asigna por el parámetro MaxNoOfConcurrentOperations.

  El valor por defecto de este parámetro es 8192. Sólo en casos raros de paralelismo extremadamente alto usando índices hash únicos debería ser necesario incrementar este valor. Usar un valor menor es posible y puede ahorrar memoria si el DBA está seguro que un cierto grado de paralelismo no es necesario en el cluster.

• [NDBD]MaxNoOfFiredTriggers

  El valor por defecto de MaxNoOfFiredTriggers es 4000, que es suficiente para la mayoría de situaciones. En algunos casos puede decrementarse si el DBA está seguro que el cluster no necesita un paralelismo alto.

  Se crea un registro cuando se realiza una operación que afecta un índice hash único. Insertar o borrar un registro en una tabla con índices hash únicos o actualizar una columna que es parte de un índice hash único provoca una inserción o borrado en la tabla índice. El registro resultante se usa para representar esta operación de la tabla índice mientras se espera a que la operación original se complete. Esta operación tiene una vida corta pero puede requerir un gran número de registros en su pool para situaciones en que muchas operaciones de escritura paralelas en una tabla base que contenga un conjunto de índices hash únicos.

• [NDBD]TransactionBufferMemory

  La memoria afectada por este parámetro se usa para tracear operaciones disparadas al actualizar tablas índice y leer índices únicos. Esta memoria se usa para almacenar la información de clave y columna para estas opraciones. Es muy raro que el valor de este parámetro necesite alterarse.

  Las operaciones normales de lectura y escritura usan un búffer similar, cuyo uso es incluso de vida más corta. El parámetro de tiempo de compilación ZATTRBUF_FILESIZE (que se encuentra en ndb/src/kernel/blocks/Dbtc/Dbtc.hpp) es 4000*128 bytes (500KB). Un buffer similar para información de claves, ZDATABUF_FILESIZE (también en Dbtc.hpp) contiene 4000*16 = 62.5KB de tamaño de búffer. Dbtc es el módulo que trata la coordinación de transacciones.

Hay parámtros adicionales en el módulo Dblqh (en ndb/src/kernel/blocks/Dblqh/Dblqh.hpp) que afecta a lecturas y actualizaciones. Incluyen ZATTRINBUF_FILESIZE, por defecto 10000*128 bytes (1250KB) y ZDATABUF_FILE_SIZE, por defecto 10000*16 bytes (unos 156KB) de tamaño de buffer. Hasta hoy, no ha habido ningún reporte de usuarios ni resultados de nuestros tests que sugieran que deba incrementarse estos límites en tiempo de compilación.

El valor por defecto de TransactionBufferMemory es 1MB.

• [NDBD]MaxNoOfConcurrentScans

  Este parámetro se usa para controlar el número de escaneos paralelos que pueden realizarse en el cluster. Cada coordinador de transacción puede tratar el número de escaneos paralelos definidos por este parámetro. Cada consulta de escaneo se realiza escaneando todas las particiones en paralelo. Cada escaneo de partición usa un registro de escaneo en el nodo donde se encuentra la partición, siendo el número de registros el valor de este parámetro por el número de nodos. El clúster debe ser capaz de sostener MaxNoOfConcurrentScans escaneos concurrentes de todos los nodos en el cluster.

  Los escaneos se realizan en dos casos. El primero cuando no existe un índice hash u ordenado para tratar la consulta, en cuyo caso la consulta se ejecuta realizando un escaneo de la tabla completa. El segundo caso se encuentra cuando no hay índice hash para soportar la consulta pero hay un índice ordenado. Usar el índice ordenado significa ejecutar un escaneo de rango paralelo. Como el orden se mantiene en las particiones locales sólo, es necesario realizar el escaneo de índice en todas las particiones.

  El valor por defecto de MaxNoOfConcurrentScans es 256. El valor máximo es 500.

  Este parámetro especifica el número de escaneos posibles en el coordinador de transacción. Si el número de registros de escaneos locales no se proporciona, se calcula como el producto de MaxNoOfConcurrentScans y el número de nodos de datos en el sistema.

• [NDBD]MaxNoOfLocalScans

  Especifica el número de registros de escaneo locales si varios escaneos no están paralelizados completamente.

• [NDBD]BatchSizePerLocalScan

  Este parámetro se usa para calcular el número de registros bloqueados que necesitan estar ahí para tratar varias operaciones de escaneo concurrentes.

  El valor por defecto es 64; este valor tiene una fuerte conexión con ScanBatchSize definido en los nodos SQL.

• [NDBD]LongMessageBuffer

  Este es un buffer interno usado para pasar mensajes entre nodos individuales y entre nodos. Aunque es muy improbable que este valor deba cambiarse, es configurable. Por defecto es 1MB.

• [NDBD]NoOfFragmentLogFiles

  Este parámetro especifica el tamaño del fichero de log REDO del nodo. Los ficheros de log REDO se organizan en un anillo. Es muy importante que el fichero primero y último del log (a veces conocidos como "cabeza" y "cola", respectivamente) no se encuentren; cuando se aproximan el uno al otro demasiado, el nodo empieza a abortar todas las transacciones que realizan actualizaciones debido a la falta de espacio para nuevos registros de log.

  Un registro de log REDO no se elimina hasta que se han completado tres checkpoints locales desde la inserción del último registro del log. Establecer checkpoints frecuentemente viene determinado por su propio conjunto de parámetros de configuración discutidos en este capítulo.

  El valor por defecto del parámetro es 8, que significa 8 conjuntos de 4 ficheros de 16MB para un total de 512MB. En otras palabras, el espacio de log REDO debe reservarse en bloques de 64MB. En escenarios que necesitan muchas actualizaciones, el valor de NoOfFragmentLogFiles puede necesitar ser tan grande como 300 o incluso mayor para proporcionar suficiente espacio para logs REDO.

  Si se hacen pocos checkpoings y hay tantas escrituras en la base de datos que los ficheros de log se llenan y la cola de logs no puede cortarse sin recuperación jeapo rdising , se abortan todas las transacciones con un código de error interno 410, o Out of log file space temporarily. Esta condición prevalecerá hasta que se complete un checkpoint y se mueva la cola de log.

• [NDBD]MaxNoOfSavedMessages

  Este parámetro especifica el máximo número de ficheros de traceo que se mantienen antes de sobreescribir los antiguos. Los ficheros de traceo se generan cuando, por alguna razón, el nodo cae.

  Por defecto son 25 ficheros de traceo.

• [NDBD]MaxNoOfAttributes

  Define el número de atributos que pueden definirse en el cluster.

  El valor por defecto para este parámetro es 1000, cuyo valor mínimo posible es 32. No hay máximo. Cada atributo consume acerca de 200 bytes de almacenamiento por nodo debido a que todos los metadatos están replicados en los servidores.

• [NDBD]MaxNoOfTables

  Se reserva un objeto tabla para cada tabla, índice hash único e índice ordenado. Este parámetro especifica el máximo número de objetos tabla para el cluster en total.

  Para cada atributo que tiene un tipo de datos BLOB se usa una tabla extra para almacenar la mayoría de datos BLOB . Estas tablas deben tenerse en cuenta al definir el número total de tablas.

  El valor por defecto es 128. El mínimo es 8 y el máximo es 1600. Cada objeto tabla consume aproximadamente 20KB por nodo.

• [NDBD]MaxNoOfOrderedIndexes

  Para cada índice ordenado en este cluster, un objeto se reserva que describe lo que se indexa y sus segmentos de almacenamiento. Por defecto cada índice definido así también define un índice ordenado. Cada índice único y clave primaria tiene un índice ordenado e índice hash.

  El valor por defecto es 128. Cada objeto consume unos 10KB de datos por nodo.

• [NDBD]MaxNoOfUniqueHashIndexes

  Para cada índice único que no sea clave primaria, se reserva una tabla especial que mapea la clave única con la clave primaria de la tabla indexada. Por defecto hay un índice ordenado que se define para cada índice único. Para evitarlo, debe usar la opción USING HASH al definir el índice único.

  El valor por defecto es 64. Cada índice consume aproximadamente 15KB por nodo.

• [NDBD]MaxNoOfTriggers

  Los disparadores internos de actualización, inserción y borrado se reservan para cada índice hash único. (Esto significa que se crean 3 disparadores para cada índice hash.) Sin embargo, un índice ordenado necesita sólo un objeto disparador. Las copias de seguridad también usan tres objetos disparadores para cada tabla normal en el cluster.

  Nota: Cuando se soporta replicación entre clusters, esta hará uso de disparadores internos.

  Este parámetro inicializa el número máximo de objetos disparadores en el cluster.

  El valor por defecto es 768.

• [NDBD]MaxNoOfIndexes

  Este parámetro está obsoleto en MySQL 5.0; debe usar MaxNoOfOrderedIndexes y MaxNoOfUniqueHashIndexes en su lugar.

  Este parámetro se usa sólo en índices hash únicos. Debe haber un registro en este pool para cada índice hash único definido en el cluster.

  El valor por defecto es 128.

• [NDBD]LockPagesInMainMemory

  Para algunos sistemas operativos, incluyendo Solaris y Linux, es posible bloquear el proceso en memoria y evitar el swapping de disco. Esto puede usarse para ayudar a garantizar las características de tiempo real del cluster.

  Por defecto, esta característica está desactivada.

• [NDBD]StopOnError

  Este parámetro especifica si un proceso NDBD debe salir o reiniciarse automáticamente cuando se encuentra una condición de error.

  Esta característica está activada por defecto.

• [NDBD]Diskless

  Es posible especificar tablas cluster como diskless, que significa que no se hacen checkpoints en disco y que no se registran. Estas tablas sólo existen en memoria. Una consecuencia de usar estas tablas es que no se pueden mantener tras una caida. Sin embargo, cuando el modo diskless está operativo se puede ejecutar ndbd en una máquina sin disco.

  Nota: Actualmente, esta característica hace que el cluster entero funcione en modo diskless.

  Actualmente, cuando está característica está activa, las copias de seguridad se realizan pero los datos no se almacenan. En futuras versiones esperamos hacer la copia de seguridad diskless un parámetro separado y configurable.

  Esta característica está activada mediante poner Diskless a 1 o Y. Diskless está desactivado por defecto.

• [NDBD]RestartOnErrorInsert

  Esta característica es accesible sólo al compilar la versión de debug cuando es posible insertar errores en la ejecución de bloques de código individuales como parte del testeo.

  Por defecto, esta característica está desactivada.

• [NDBD]TimeBetweenWatchDogCheck

  Para evitar que el flujo principal quede en un bucle sin fin en algún punto, un “watchdog” chequea el flujo principal. Este parámetro especifica el número de milisegundos entre chequeos. Si el proceso sigue siendo el mismo tras tres chequeos, lo mata el flujo watchdog.

  Este parámetro puede cambiarse fácilmente para propósitos de experimentación o para adaptar las condiciones locales. Puede especificarse por nodo aunque parece que no hay grandes razones para hacerlo.

  El timeout por defecto es de 4000 milisegundos (4 segundos).

• [NDBD]StartPartialTimeout

  Este parámetro especifica lo que esperará el cluster para que arranquen los nodos de almacenamiento cuando se invoca la rutina de inicialización . Este timeout se usa para evitar un arranque parcial del cluster cuando es posible.

  El valor por defecto es de 30000 milisegundos (30 segundos). 0 significa timeout eterno; en otras palabras, el cluster puede arrancar sólo si todos los nodos están disponibles.

• [NDBD]StartPartitionedTimeout

  Si el cluster está preparado para arrancar tras esperar durante StartPartialTimeout milisegundos pero todavía es posible en un estado particionado, el cluster espera hasta que este timeout pasa.

  El timeout por defecto es 60000 milisegundos (60 segundos).

• [NDBD]StartFailureTimeout

  Si un nodo de datos no ha completado su secuencia de arranque en el tiempo especificado por este parámetro, el arranque del nodo falla. Poner este parámetro a 0 significa que no se aplica ningún timeout para el nodo de datos.

  El valor por defecto es 60000 milisegundos (60 segundos). Para los nodos de datos con cantidades de datos extremadamente grandes, este parámetro debe incrementarse. Por ejemplo, en el caso de un nodo de almacenamiento que contenga varios gigabytes de datos, un perido de 10-15 minutos (esto es, 600,000 a 1,000,000 milisegundos) puede ser necesario para realizar una reinicialización de nodo.

• [NDBD]HeartbeatIntervalDbDb

  Uno de los métodos primarios de descubrimiento de nodos fallidos es el uso de heartbeats. Este parámetro refleja la frecuencia con que las señales heartbeat se envían y con que frecuencia se espera su recepción. Tras perder tres intervalos heartbeat seguidos, el nodo se declara muerto. Así el máximo tiempo para descubrir un fallo a través del mecanismo heartbeat es cuatro veces el intervalo heartbeat.

  El intervalo de heartbeat por defecto es de 1500 milisegundos (1.5 segundos). Este parámetro no debe cambiarse drásticamente y no debe variar demasiado entre nodos. Si un nodo usa 5000 milisegundos y el nodo observador usa 1000 milisegundos entonces óbviamente se declarará muerto rápidamente. Este parámetro puede cambiarse durande una actualización de software en línea pero sólo en pequeños incrementos.

• [NDBD]HeartbeatIntervalDbApi

  Cada nodo de datos envía señales heartbeat a cada MySQL server (nodo SQL ) para segurar que permanece en contacto. Si un MySQL server falla para enviar un heartbeat a tiempo se declara “muerto”, en cuyo caso todas las transacciones activas se completan y todos los recursos se liberan. El nodo SQL no puede reconectar hasta que todas las actividades iniciadas por la instancia MySQL prévia se ha completado. El criterio de tres heartbeats para esta discriminación es la misma que se describe en HeartbeatIntervalDbDb.

  El intervalo por defecto es de 1500 milisegundos (1.5 segundos). Este intervalo puede variar entre nodos de datos individuales ya que cada nodo de almacenamiento vigila los servidores MySQL conectados a ellos, independientemente de todos los otros nodos de datos..

• [NDBD]TimeBetweenLocalCheckpoints

  Este parámetro es una excepción en que no especifica un tiempo para esperar antes de arrancar un nuevo checkpoint local; en lugar de esto, se usa para asegurarse que los checkpoints locales no se realizan en un cluster donde tienen lugar relativamente pocas actualizaciones. En la mayoría de clusters con altos ratios de actualización, es probable que se arranquen checkpoints locales inmediatamente tras que se hayan completado los previos.

  El tamaño de todas las operaciones de escritura ejecutadas desde el arranque de los chekpoints locales prévios. Este parámetro es excepcional ya que se especifica como el logaritmo en base 2 del número de palabras de 4 bytes, así que el valor por defecto 20 significa 4MB (4 * 2²⁰) de operaciones de escritura, 21 significaría 8MB, y así hasta un máximo de 31, que son 8GB de operaciones de escritura.

  Todas las operaciones de escritura en el cluster se añaden juntas. Poner TimeBetweenLocalCheckpoints a 6 o menos significa que los checkpoints locales se ejecutarán contínuamente sin pausa, independientemente de la carga de trabajo del cluster.

• [NDBD]TimeBetweenGlobalCheckpoints

  Cuando se hace un commit de una transacción, se realiza en memoria principal en todos los nodos en que los datos se replican. Sin embargo, los registros del log de transacción no se vuelcan en disco como parte del commit. El razonamiento de este comportamiento es que tener la transacción con un commit en al menos dos máquinas autónomas debe cumplir estándars razonables para durabilidad.

  También es importante asegurarse que incluso el peor caso — una caída completa del cluster — se trata apropiadamente . Para garantizar que esto ocurre, todas las transacciones que tienen lugar dentro de un intervalo dado se ponen en un checkpoint global, que puede entenderse como un conjunto de transacciones volcadas en disco. En otras palabras, como parte del proceso de commit, una transacción se guarda en el grupo de checkpoint global; posteriormente, este registro de log de grupo se vuelca en disco, y luego se guarda en disco el completo grupo de transacciones en todas las máquinas del cluster.

  Este parámetro define el intervalo entre checkpoints globales. Por defecto son 2000 milisegundos.

• [NDBD]TimeBetweenInactiveTransactionAbortCheck

  El tratamiento de time-outs se realiza chequeando un timer en cada transacción una vez por cada intervalo especificado por este parámetro. Por lo tanto, si este parámetro se pone a 1000 milisegundos, cada transacción se chequea para hacer un time out una vez por segundo.

  El valor por defecto para este parámetro es 1000 milisegundos (1 segundo).

• [NDBD]TransactionInactiveTimeout

  Si la transacción no está realizando ninguna consulta pero esta esperando más datos de entrada del usuario, este parámetro indica el tiempo máximo que el usuario puede esperar entes de abortar la transacción.

  Por defecto este parámetro es cero (no timeout). Para una base de datos en tiempo real que necesita asegurarse que las transacciones no mantienen bloqueos demasiado tiempo se debe inicializar con un valor mucho más pequeño. La unidad es milisegundos.

• [NDBD]TransactionDeadlockDetectionTimeout

  Cuando un nodo ejecuta una consulta que implique una transacción, el nodo espera para que respondan los otros nodos en el cluster antes de continuar. Puede que haya un fallo al responder por cualquiera de las siguientes razones:

  1. El nodo está “muerto”

  2. La operación ha entrado en una cola de bloqueo

  3. El nodo con la petición de realizar la acción puede estar muy sobrecargado.

  Este parámetro de timeout indica cuánto espera el coordinador de la transacción para la ejecución de la consulta por otro nodo antes de abortar la transacción, y es importante para tratamiento de fallo de nodo y detección de deadlocks. Ponerlo a un valor muy alto puede causar comportamiento no deseables en situaciones que impliquen deadlocks y fallos de nodos.

  El timeout por defecto es 1200 milisegundos (1.2 segundos).

• [NDBD]NoOfDiskPagesToDiskAfterRestartTUP

  Al ejecutar un checkpoint local el algoritmo vuelca todas las páginas de datos a disco. Hacer esto tan rápidamente como sea posible sin ninguna moderación es posible que imponga demasiada carga de procesador, red y disco. Para controlar la velocidad de escritura, este parámetro especifica cuántas paginas se escriben en 100 milisegundos. En este contexto, una “página” se define como 8KB; por lo tanto, este parámetro se especifica en unidades de 80KB por segundo. Por lo tanto, poner NoOfDiskPagesToDiskAfterRestartTUP a un valor de 20 significa escribir 1.6MB de páginas de datos en disco cada segundo durante checkpoints locales. Este valor incluye escribir registros del log UNDO para páginas de datos; esto es, este parámetro trata la limitación de escrituras de memoria de datos. Los registros del log UNDO para páginas de índice se tratan mediante los parámetros NoOfDiskPagesToDiskAfterRestartACC. (Consulte la entrada para IndexMemory para información acerca de páginas de índice.)

  Resumiendo, este parámetro especifique con qué velocidad se realizan los checkpoints locales, y opera en conjunción con NoOfFragmentLogFiles, DataMemory, y IndexMemory.

  El valor por defecto es 40 (3.2MB de páginas de datos por segundo).

• [NDBD]NoOfDiskPagesToDiskAfterRestartACC

  Este parámetro usa las mismas unidades que NoOfDiskPagesToDiskAfterRestartTUP y actúa de forma similar, pero limita la velocidad de escritura de páginas índices de memoria índice.

  El valor por defecto de este parámetro es 20 páginas índice de memoria por segundo (1.6MB por segundo).

• [NDBD]NoOfDiskPagesToDiskDuringRestartTUP

  Este parámero parecido a NoOfDiskPagesToDiskAfterRestartTUP y NoOfDiskPagesToDiskAfterRestartACC, sólo lo hace en función de los checkpoints locales ejecutados en el nodo donde se reinicia un nodo. Como parte de todo reinicio de nodo siempre se realiza un checkpoint. Durante el reinicio de un nodo es posible escribir en disco a una velocidad superior que otras veces, ya que se realizan menos actividades en el nodo.

  Este parámetro cubre páginas escritas de memoria de datos.

  El valor por defecto es 40 (3.2MB por segundo).

• [NDBD]NoOfDiskPagesToDiskDuringRestartACC

  Controla el número de páginas de memoria índice que pueden escribirse en disco durante la fase de checkpoint local del reinicio de un nodo.

  Como con NoOfDiskPagesToDiskAfterRestartTUP y NoOfDiskPagesToDiskAfterRestartACC, los valores para este parámetro se expresan en términos de 8KB páginas escritas en 100 milisegundos (80KB/segundo).

  El valor por defecto es 20 (1.6MB por segundo).

• [NDBD]ArbitrationTimeout

  Este parámetro especifica el tiempo que esperará el nodo de datos en respuesta al árbitro. Si se excede, se asume que la red se ha partido.

  El valor por defecto es de 1000 milisegundos (1 segundo).

• [NDBD]UndoIndexBuffer

  Este buffer se usa durante los checkpoints locales. El motor NDB usa un esquema de recuperación basado en consistencia de checkpoints en conjunción con un log REDO operacional. Para producir un checkpoint consistente con bloquear el sistema entero para escrituras, el logueo de UNDO se hace mientras se realiza el checkpoint local. El logueo UNDO se activa en un fragmento de tabla único cada vez. Esta optimización es posible porque las tablas se almacenan completamente en memoria.

  El buffer UNDO índice se usa para las actualizaciones en el índice de clave hash primaria. Las inserciones y borrados modifican el índice hash; el motor NDB escribe registros en el log UNDO que mapean todos los cambios físicos en una página índice de forma que pueden deshacerse al reiniciar al sistema. También loguea todas las operaciones de inserciones activas para cada fragmento al arranque del checkpoint local.

  Lee y actualiza el conjunto de bits de bloquea y actualiza una cabecera en la entrada del índice hash. Estos cambios los trata el algoritmo de escritura de páginas para asegurar que estas operaciones no necesitan logueo UNDO.

  Este búffer es de 2MB por defecto. El valor mínimo es de 1MB, y para la mayoría de aplicaciones el mínimo es suficiente. Para aplicaciones que realicen un número de inserciones y borrados muy alto junto con transacciones muy grandes y claves primaria grandes, puede ser necesario incrementar el tamaño de este buffer. Si el buffer es muy pequeño, el motor NDB realiza un código de error interno 677 Index UNDO buffers overloaded.

• [NDBD]UndoDataBuffer

  El buffer de datos UNDO juega el mismo rol que el buffer de indice UNDO, excepto que se usa a con la memoria de datos en lugar de la de índice. Este buffer se usa durante la fase de checkpoint local de un fragmento para inserciones, borrados y actualizaciones.

  Como UNDO las entradas de log tienden a crecer mayores mientras más operaciones se loguean, este buffer también es mayor que su contraparte de memoria índice, con un valor por defecto de 16MB.

  Para algunas aplicaciones esta cantidad de memoria puede ser innecesariamente grande. En tales casos es posible decrementar este tamaño a un mínimo de 1MB.

  Ráramente es necesario incrementar el tamaño de este buffer. Si hay tal necesidad, es una buena idea chequear si el disco puede tratar la carga causada por la actividad de actualización de la base de datos. Una falta de espacio de disco no puede evitarse incrementando el tamaño de este buffer.

  Si este buffer es demasiado pequeño y se congestiona, el motor NDB realiza un código de error interno 891 Data UNDO buffers overloaded.

• [NDBD]RedoBuffer

  Todas las actividades de actualización necesitan loguearse. Este log hace posible rehacer estas actualizaciones cuando el sistema se reinicia. El algoritmo de recuperación NDB usa un checkpoint “fuzzy” de los datos junto con el log UNDO, luego aplica el log REDO para aplicar todos los cambios hasta el punto de restauración.

  Este buffer es de 8MB por defecto. El valor mínimo es 1MB.

  Si este buffer es demasiado pequeño, el motor NDB realiza un código de error 1221 REDO log buffers overloaded.

• [NDBD]LogLevelStartup

  Reportar niveles para eventos generados durante el arranque del proceso.

  El nivel por defecto es 1.

• [NDBD]LogLevelShutdown

  El nivel de reporte para eventos generados como parte de un cierre de un nodo.

  El nivel por defecto es 0.

• [NDBD]LogLevelStatistic

  El nivel de reporte para eventos estadísticos tales como número de lecturas de clave primaria, número de actualizaciones, número de inserciones, información acerca del uso de búffer, y así.

  El nivel por defecto es 0.

• [NDBD]LogLevelCheckpoint

  Nivel de reporte para eventos generados por los checkpoints locales y globales.

  El nivel por defecto es 0.

• [NDBD]LogLevelNodeRestart

  Nivel de reporte para eventos generados durante reinicio de nodo.

  El nivel por defecto es 0.

• [NDBD]LogLevelConnection

  El nivel de reporte para eventos generados por conexiones entre nodos del cluster.

  El nivel por defecto es 0.

• [NDBD]LogLevelError

  Nivel de reporte para eventos generados por errores y advertencias por el cluster global. Estos errores no causan ningún fallo de nodo pero se considera que vale la pena de reportar.

  El nivel por defecto es 0.

• [NDBD]LogLevelInfo

  Nivel de reporte para eventos generados por información acerca del estado general del cluster.

  El nivel por defecto es 0.

• [NDBD]BackupDataBufferSize

  Al crear una copia de seguridad, hay dos búffers usados para enviar data a disco. El buffer de copia de seguridad de datos se usa para rellenar con datos registrados al escanear las tablas de un nodo. Una vez que este buffer se ha rellenado al nivel especificado por BackupWriteSize (vea a continuación), las páginas se envían a disco. Al volcar los datos a disco, el proceso de copia de seguridad puede continuar rellenando este buffer hasta que se queda sin espacio. Cuando ocurre, el proceso de copia de seguridad pausa el escaneo y espera hasta que se completan algunas escrituras en disco y han liberado memoria de forma que pueda continuar el escaneo.

  El valor por defecto de este paráemtro es 2MB.

• [NDBD]BackupLogBufferSize

  El buffer de log de copia de seguridad tiene un rol similar al jugado por el buffer de copia de seguridad de datos , excepto que se usa para generar un log de todas las escrituras de tabla realizadas durante la ejecución de una copia de seguridad. Los mismos principios se aplican para escribir estas páginas como con el buffer de datos de copia de seguridad, excepto que cuando no hay más espacio en el buffer de log de copia de seguridad, la copia falla. Por esta razón, el tamaño del buffer de log de copia de seguridad debe ser lo bastante grande para tratar la carga causada por las actividades de escritura mientras se realiza la copia de seguridad.

  El valor por defecto de este parámetro debe ser suficiente para la mayoría de aplicaciones. De hecho, es más fácil que un fallo de copia de seguridad sea causado por velocidad de escritura en disco insuficiente que por que el buffer de log esté lleno. Si el subsistema de disco no está configurado para la carga de escritura causada por las aplicaciones, el cluster posiblemente será capaz de realizar las operaciones deseadas.

  Es preferible configurar nodos del cluster de forma que el procesador sea el cuello de botella en lugar que los discos o las conexiones de red.

  El valor por defecto es 2MB.

• [NDBD]BackupMemory

  Este parámetro es la suma de BackupDataBufferSize y BackupLogBufferSize.

  El valor por defecto es 2MB + 2MB = 4MB.

• [NDBD]BackupWriteSize

  Este parámetro especifica el tamaño de los mensajes escritos en disco por los buffers de log y datos de copia de seguridad.

  El valor por defecto es 32KB.