Hola usuario de nuestra web, hallamos la solución a lo que buscabas, deslízate y la obtendrás a continuación.
El motor de almacenamiento FederatedX se lanzó por primera vez en MariaDB 5.1.
El motor de almacenamiento FederatedX es una bifurcación de MySQL Motor de almacenamiento federado, que ya no está siendo desarrollado por Oracle. El propósito original de FederatedX era mantener el progreso del desarrollo de este motor de almacenamiento, tanto para agregar nuevas funciones como para corregir errores antiguos.
Desde MariaDB 10.0, el motor de almacenamiento CONNECT también permite el acceso a una base de datos remota a través de una conexión MySQL u ODBC (tipos de tabla: MYSQL, ODBC). Sin embargo, en la implementación actual existen varias limitaciones.
¿Qué es el motor de almacenamiento FederatedX?
FederatedX Storage Engine es un motor de almacenamiento que funciona tanto con MariaDB como con MySQL. Donde otros motores de almacenamiento se construyen como interfaces para almacenes de datos basados en archivos de nivel inferior, FederatedX usa libmysql para comunicarse con la fuente de datos, siendo la fuente de datos un RDBMS remoto. Actualmente, dado que FederatedX solo usa libmysql, solo puede comunicarse con otro RDBMS de MySQL. El plan es, por supuesto, poder utilizar otros sistemas RDBMS como fuente de datos. Existe un proyecto existente Federated ODBC que pudo usar PostgreSQL como fuente de datos remota, y es este tipo de funcionalidad la que se traerá a FederatedX en versiones posteriores.
Historia
La historia de FederatedX se deriva de la Historia de Federated. Cisco necesitaba un motor de almacenamiento MySQL que les permitiera consolidar tablas remotas en algún tipo de dispositivo de enrutamiento, pudiendo interactuar con estas tablas remotas como si fueran locales del dispositivo, pero no realmente en el dispositivo, ya que el dispositivo de enrutamiento tenía solo una cantidad limitada de espacio de almacenamiento. El primer prototipo del motor de almacenamiento federado fue desarrollado por JD (es necesario verificar esto, Brian Aker puede verificar) utilizando la interfaz HANDLER. Brian le entregó el código a Patrick Galbraith y le explicó cómo debía funcionar, y con la tutela de Brian y Monty, Patrick tenía un motor de almacenamiento federado en funcionamiento con MySQL 5.0. Finalmente, Federated se lanzó al público en una versión de MySQL 5.0.
Cuando MySQL 5.1 se convirtió en la versión de producción de MySQL, Federated tenía más funciones y mejoras agregadas, a saber:
- Nuevo SERVIDOR federado agregado al analizador. Esto era algo que Cisco necesitaba que hiciera posible cambiar los parámetros de conexión para numerosas tablas federadas a la vez sin tener que alterar o volver a crear las tablas federadas.
- Soporte transaccional básico: para admitir tablas transaccionales remotas
- Varios errores que debían corregirse desde MySQL 5.0
- Capacidad de complemento
En MariaDB 10.0.2 FederatedX obtuvo soporte para el descubrimiento de tablas asistido.
Instalación del complemento
Aunque la biblioteca compartida del complemento se distribuye con MariaDB de forma predeterminada, MariaDB no instala el complemento de forma predeterminada. Hay dos métodos que se pueden utilizar para instalar el complemento con MariaDB.
El primer método se puede utilizar para instalar el complemento sin reiniciar el servidor. Puede instalar el complemento dinámicamente ejecutando INSTALL SONAME o INSTALL PLUGIN. Por ejemplo:
INSTALL SONAME'ha_federatedx';
El segundo método se puede utilizar para decirle al servidor que cargue el complemento cuando se inicie. El complemento se puede instalar de esta manera proporcionando el --plugin-load o la --plugin-load-add opciones. Esto se puede especificar como un argumento de línea de comandos para mysqld o se puede especificar en un grupo de opciones de servidor relevante en un archivo de opciones. Por ejemplo:
[mariadb]... plugin_load_add = ha_federatedx
Desinstalar el complemento
Puede desinstalar el complemento dinámicamente ejecutando UNINSTALL SONAME o UNINSTALL PLUGIN. Por ejemplo:
UNINSTALL SONAME'ha_federatedx';
Si instaló el complemento proporcionando el --plugin-load o la --plugin-load-add opciones en un grupo de opciones de servidor relevante en un archivo de opciones, entonces esas opciones deben eliminarse para evitar que el complemento se cargue la próxima vez que se reinicie el servidor.
Cómo funciona FederatedX
Cada motor de almacenamiento tiene que implementar métodos API de clase de controlador estándar derivados para que funcione un motor de almacenamiento. FederatedX no es diferente en ese sentido. La gran diferencia es que FederatedX necesita implementar estos métodos de manejo para construir sentencias SQL para ejecutar en el servidor remoto y, si hay un conjunto de resultados, procesar ese conjunto de resultados en el formato de controlador interno para que el resultado se devuelva al usuario.
Funcionamiento interno de FederatedX
Los archivos de base de datos normales son locales y, como tales: usted crea una tabla llamada ‘usuarios’, se crea un archivo como ‘usuarios.MYD’. Un manejador lee, inserta, elimina y actualiza datos en este archivo. Los datos se almacenan en un formato particular, por lo que para leer, esos datos deben analizarse en campos, para escribir, los campos deben almacenarse en este formato para escribir en este archivo de datos.
Con el motor de almacenamiento FederatedX, no habrá archivos locales para los datos de cada tabla (como .MYD). Una base de datos ajena almacenará los datos que normalmente estarían en este archivo. Esto requerirá el uso de la API del cliente MySQL para leer, eliminar, actualizar e insertar estos datos. Los datos deberán recuperarse mediante una llamada SQL “SELECT*FROMusers“. Luego, para leer estos datos, deberá recuperarlos a través de mysql_fetch_row una fila a la vez, luego se convierte de la columna en esta selección al formato que espera el controlador.
La funcionalidad básica de cómo funciona FederatedX es:
- El usuario emite una sentencia SQL contra la tabla federatedX local. Esta declaración se analiza en un árbol de elementos
- FederatedX utiliza la API del controlador mysql para implementar los diversos métodos necesarios para un motor de almacenamiento. Tiene acceso al árbol de elementos de la sentencia SQL emitida, así como al objeto Table y a cada uno de sus miembros Field. A
- Con esta información, FederatedX construye una declaración SQL
- La declaración SQL construida se envía a la fuente de datos externa a través de libmysql usando la API del cliente mysql
- La base de datos externa lee la declaración SQL y envía el resultado a través de la API del cliente mysql al origen
- Si la declaración SQL original tiene un conjunto de resultados de la fuente de datos externa, el motor de almacenamiento FederatedX itera a través del conjunto de resultados y convierte cada fila y columna al formato de controlador interno.
- Si la declaración SQL original solo devuelve el número de filas devueltas (influence_rows), ese número se agrega a las estadísticas de la tabla, lo que hace que el usuario vea cuántas filas se vieron afectadas.
Creación de tablas FederatedX
La tabla de creación simplemente creará el archivo .frm, y dentro del CREATETABLE Instrucción SQL, habrá cualquiera de los siguientes:
connection=scheme://username:[email protected]:port/database/tablename connection=scheme://[email protected]/database/tablename connection=scheme://username:[email protected]/database/tablename connection=scheme://username:[email protected]/database/tablename
O usando la sintaxis introducida en MySQL versiones 5.1 para un servidor federado (SQL / MED Spec xxxx)
connection="connection_one" connection="connection_one/table_foo"
Un ejemplo de una cadena de conexión que especifica todos los parámetros de conexión sería:
connection=mysql://username:[email protected]:port/database/tablename
O, utilizando un servidor federado, primero se crea un servidor:
create server 'server_one'foreigndata wrapper 'mysql' options (HOST '127.0.0.1',DATABASE'db1',USER'root', PASSWORD '', PORT 3306, SOCKET '', OWNER 'root');
Luego, se crea la tabla FederatedX especificando el servidor federado recién creado:
CREATETABLE federatedx.t1 (`id`int(20)NOTNULL,`name`varchar(64)NOTNULLdefault'')ENGINE="FEDERATED"DEFAULTCHARSET=latin1 CONNECTION='server_one';
(Tenga en cuenta que en MariaDB, el motor de almacenamiento federado original se reemplaza por el nuevo motor de almacenamiento FederatedX. Y para compatibilidad con versiones anteriores, el nombre anterior “FEDERATED” se usa en la tabla de creación. Por lo tanto, en MariaDB, el tipo de motor debe ser “FEDERATED “sin una” X “adicional, no” FEDERATEDX “).
El equivalente de lo anterior, si se termina especificando todos los parámetros de conexión
CONNECTION="mysql://[email protected]:3306/db1/t1"
También puede cambiar el servidor para que apunte a un nuevo esquema:
ALTER SERVER 'server_one' options(DATABASE'db2');
¡Todas las llamadas posteriores a cualquier tabla FederatedX utilizando ‘server_one’ ahora serán contra db2.t1! ¿Adivina qué? ¡Ya no tiene que realizar una alteración de la tabla para apuntar una o más tablas FederatedX a un nuevo servidor!
Esta connection="connection string" es necesario para que el controlador pueda conectarse al servidor externo, ya sea por URL o por nombre de servidor.
Llamadas a métodos
Una forma de ver cómo funciona el motor de almacenamiento FederatedX es compilar una compilación de depuración de MariaDB y activar un registro de seguimiento. Utilizando una tabla de dos columnas, con un registro, se pueden analizar las siguientes sentencias SQL que se muestran a continuación para determinar qué métodos internos resultan en ser llamados.
SELECCIONE
Si la consulta es, por ejemplo “SELECT*FROMfoo“, entonces los métodos principales que vería con la depuración activada serían primero:
ha_federatedx::info ha_federatedx::scan_time: ha_federatedx::rnd_init: share->select_query SELECT*FROM foo ha_federatedx::extra
Luego, para cada fila de datos recuperados de la base de datos externa en el conjunto de resultados:
ha_federatedx::rnd_next ha_federatedx::convert_row_to_internal_format ha_federatedx::rnd_next
Después de todas las filas de datos que se recuperaron, verá:
ha_federatedx::rnd_end ha_federatedx::extra ha_federatedx::reset
INSERTAR
Si la consulta fue “INSERTINTOfoo(id,ts)VALUES(2,now());“, la traza sería:
ha_federatedx::write_row ha_federatedx::reset
ACTUALIZAR
Si la consulta fue “UPDATEfooSETts=now()WHEREid=1;“, la traza resultante sería:
ha_federatedx::index_init ha_federatedx::index_read ha_federatedx::index_read_idx ha_federatedx::rnd_next ha_federatedx::convert_row_to_internal_format ha_federatedx::update_row ha_federatedx::extra ha_federatedx::extra ha_federatedx::extra ha_federatedx::external_lock ha_federatedx::reset
Capacidades y limitaciones de FederatedX
- Las tablas DEBEN crearse en el servidor externo antes de cualquier acción en esas tablas a través del controlador, primera versión. IMPORTANTE: SI DEBE usar el tipo de motor de almacenamiento FederatedX en el extremo REMOTO, asegúrese de que la mesa a la que se conecta NO ES una mesa que apunte hacia su mesa ORIGINAL. ¿Conoce y ha escuchado el chirrido de la retroalimentación de audio? ¿Sabes poniendo dos espejos uno frente al otro cómo el reflejo continúa por la eternidad? Bueno, ¿necesito decir más?
- No hay forma de que el controlador sepa si la base de datos o tabla externa ha cambiado. La razón de esto es que esta base de datos tiene que funcionar como un archivo de datos en el que nunca se escribiría nada más que la base de datos. La integridad de los datos en la tabla local podría violarse si hubiera algún cambio en la base de datos externa.
- Soporte para índices SELECT, INSERT, UPDATE, DELETE.
- No hay llamadas ALTER TABLE, DROP TABLE o cualquier otro lenguaje de definición de datos.
- Las declaraciones preparadas no se utilizarán en la primera implementación, queda por ver si el subconjunto limitado de la API del cliente para el servidor lo admite.
- Utiliza SELECT, INSERT, UPDATE, DELETE y no HANDLER para su implementación.
- Esto no funcionará con la caché de consultas.
¿Cómo se usa FederatedX?
Utilizar este controlador es muy sencillo. Debe tener dos bases de datos en ejecución, ambas en el mismo host o en diferentes hosts.
Primero, en la base de datos externa crea una tabla, por ejemplo:
CREATETABLE test_table ( id int(20)NOTNULLauto_increment, name varchar(32)NOTNULLdefault'', other int(20)NOTNULLdefault'0',PRIMARYKEY(id),KEY name (name),KEY other_key (other))DEFAULTCHARSET=latin1;
Luego, en el servidor que se conectará al host externo (cliente), crea una tabla federada sin especificar la estructura de la tabla:
CREATETABLE test_table ENGINE=FEDERATED CONNECTION='mysql://[email protected]:9306/federatedx/test_federatedx';
¿Observa los campos “MOTOR” y “CONEXIÓN”? Aquí es donde se configura respectivamente el tipo de motor, “FEDERADO” y la información del host externo, siendo esta la base de datos a la que se conectará su base de datos “cliente” y la utilizará como “archivo de datos”. Obviamente, la base de datos externa se está ejecutando en el puerto. 9306, por lo que desea iniciar su otra base de datos para que esté en el puerto 9306, y su base de datos FederatedX en un puerto diferente a ese. En mi configuración, uso el puerto 5554 para FederatedX y el puerto 5555 para la base de datos externa.
Alternativamente (o si está utilizando MariaDB antes de la versión 10.0.2), especifica la estructura de la tabla federada explícitamente:
CREATETABLE test_table ( id int(20)NOTNULLauto_increment, name varchar(32)NOTNULLdefault'', other int(20)NOTNULLdefault'0',PRIMARYKEY(id),KEY name (name),KEY other_key (other))ENGINE=FEDERATED DEFAULTCHARSET=latin1 CONNECTION='mysql://[email protected]:9306/federatedx/test_federatedx';
En este caso, la estructura de la tabla debe coincidir exactamente con la tabla del servidor externo.
Cómo ver el motor de almacenamiento en acción
Al desarrollar este controlador, compilé la base de datos FederatedX con depuración:
./configure --with-federatedx-storage-engine --prefix=/home/mysql/mysql-build/federatedx/ --with-debug
Una vez compilado, hice un ‘make install’ (no con el propósito de instalar el binario, sino para instalar todos los archivos que el binario espera ver en el directorio que especifiqué en la compilación con
--prefix=/home/code-dev/maria
Luego, inicié el servidor externo:
/usr/local/mysql/bin/mysqld_safe --user=mysql --log=/tmp/mysqld.5555.log -P 5555
Luego, volví al directorio que contiene el mysqld recién compilado
gdb ./mysqld
Luego, dentro del indicador (gdb):
(gdb) run --gdb --port=5554 --socket=/tmp/mysqld.5554 --skip-innodb --debug
A continuación, abro varias ventanas para cada una:
- Cola del seguimiento de depuración: tail -f /tmp/mysqld.trace|grep ha_fed
- Cola de las llamadas SQL a la base de datos externa: tail -f /tmp/mysqld.5555.log
- Una ventana con un cliente abierto al servidor federatedx en el puerto 5554
- Una ventana con un cliente abierto al servidor federatedx en el puerto 5555
Crearía una tabla en el cliente para el servidor externo en el puerto 5555, y luego en el servidor FederatedX en el puerto 5554. En este punto, ejecutaría las consultas que quisiera en el servidor FederatedX, recordando siempre que cualquier cambio que quería hacer en la mesa, o si creaba nuevas tablas, tendría que hacerlo en el servidor externo.
Otra cosa que debe buscar es ‘mostrar variables’ para mostrarle que tiene soporte para el controlador FederatedX:
show variables like'%federat%'
y:
show storage engines;
Ambos deben mostrar el controlador de almacenamiento federatedx.
¿Cómo creo un servidor federado?
Un servidor federado es una forma de tener una fuente de datos ajena definida, con todos los parámetros de conexión, para que no tenga que especificar explícitamente los parámetros de conexión en una cadena.
Por ejemplo, digamos que si quisiera crear una tabla, t1, que especificaría con
connection="mysql://[email protected]/first_db/t1"
En su lugar, podría crear esto con un servidor:
create server 'server_one'foreigndata wrapper 'mysql' options (HOST '192.168.1.123',DATABASE'first_db',USER'patg', PASSWORD '', PORT 3306, SOCKET '', OWNER 'root');
En su lugar, puede especificar el servidor en lugar de la cadena de conexión de URL completa
connect="server_one"
¿En qué se diferencia FederatedX del antiguo motor federado?
FederatedX desde el punto de vista del usuario es lo mismo en su mayor parte. Lo que es diferente con FederatedX y Federated es lo siguiente:
- Reescriba el código fuente federado principal de un solo archivo ha_federated.cc en tres componentes abstractos principales:
- ha_federatedx.cc – Implementación principal de FederatedX
- federated_io.cc: clase de conexión principal que las clases derivadas anularán para cada biblioteca RDBMS / cliente
- federatated_io_
.cc: clase federated_io derivada para un RDBMS determinado - federated_txn.cc: nuevo soporte para el uso de motores transaccionales en el servidor externo mediante una encuesta de conexión
- Varios errores corregidos (es necesario mirar los errores abiertos para Federated)
¿Dónde puedo conseguir FederatedX?
FederatedX es parte de MariaDB 5.1 y versiones posteriores. MariaDB se fusionó con la última versión de FederatedX cuando es necesario corregir un error. Puede obtener el último código / seguir / participar en el proyecto desde el Página de inicio de FederatedX.
¿Cuáles son los planes para FederatedX?
- Soporte para otros proveedores de RDBMS que utilizan ODBC
- Soporte para condiciones de empuje
- Capacidad para limitar el tamaño del conjunto de resultados
El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.