Is it possible create/configure MySQL for functionality like SQL Server's Linked Server?
If yes, would you please tell me how? I'm using MySQL 5.5.
MySQL's FEDERATED engine provides functionality similar to SQL Server's Linked Server (and Oracle's dblink) functionality, but doesn't support connecting to vendors other than MySQL. It's not clear from the question if you need the functionality to connect to vendors other than MySQL.
You might want to look into MySQL Proxy. This doesn't match the architecture of Linked Servers/dblink, but you can probably solve a similar set of problems that you would use Linked Servers/dblink to solve.
I am the developer of the MySQL Data Controller. Unfortunately, since we had lack of requests we have stopped development on it. The plugin was 100% functional with MySQL connecting to Oracle, MSSQL or MySQL.
Base on some requests, we had added back a blog and video about it :
http://www.acentera.com/mysql-datacontroller/
Regards,
Francis L.
Unfortunately you cannot link an entire MySQL database to another MySQL database like you can with MS SQL. However, you can link individual tables. A federated table is a local table you create that points to a table on another server.
You can run queries and stored procedures just like any other table. The two tables must have the same structure, except the Federated table uses a different database engine: Federated. If you make ANY changes to the structure of the remote table, you should re-create the local federated table.
The process is actually quite easy, here is an example: https://docs.oracle.com/cd/E17952_01/mysql-5.0-en/federated-use.html
In my experience, the time needed to create and implement this process is minimal, even when compared to linked servers. It should take you less than 30 minutes to get your first federated table working, after that its a 5 min process. Last item, when naming your federated table, I give it the same name as the remote table with a "federated_" in front, like federated_customer.
Also, store your federated table definitions as separate stored procedures so you can reuse them anytime you need to create the federated table again, AND so that other developers can see how you generated the federated table.
The MySQL Data Controller is a follow-on to the federated engine that allows connection to different database types, such as Microsoft SQL Server or Oracle. I am not sure how development is going, yet.
See: http://en.wikipedia.org/wiki/MySQL_DataController
or: https://launchpad.net/datacontroller
Related
Oracle's database link allows user to query on multiple physical databases.
Is there any MySQL equivalent ? Workaround ?
I want to run a join query on two tables , which are in two physical databases. Is it possible in MySQL ?
I can think of four possible workarounds for your scenario:
use fully-qualified-table-names when querying for the external table. MySQL supports the dbname.tablename-syntax to access tables outside the current database scope. This requires that the currently connected user has the appropriate rights to read from the requested table in another physical db.
if your external database is running on a different MySQL server (either on the same machine or via a network connection) you could use replication to constantly update a read-only copy of the remote table. Replication is only possible if you're running two separate MySQL instances.
use the FEDERATED MySQL storage engine to virtually import the table into your current database. This lifts the requirement of giving the current user access rights into the second database as the credentials are given with the CREATE TABLE-statement when using the FEDERATED storage engine. This also works with the databases running on different physical servers or different MySQL instances. I think that this will be the poorest performing option and does have some limitations - more or less important depending on your usage scenario and your requirements.
This is an extension to method 1. Instead of having to specify the fully-qualified-table-names every time you request information from your external table, you simply can create a view inside your current database based on a simple SELECT <<columns>> FROM <<database>>.<<table>>. This resemble the way, the FEDERATED-method works, but is limited to tables on the same MySQL instance.
Personally I'd consider method (4) as the most useful - but the others could also be possible workarounds depending on your requirements.
There's no MySQL equavilent method at the moment, see this post. However as the poster suggest you can do a work-around if the databases are on the same machine, by just adding the database-name in front of the table-name.
Also see this, it's 6 years old, but still not resolved. It's closed and probably not on their todo-list anymore.
I have a table in MySQL that I need to join with a couple of tables in a different server. The catch is that these other tables are in Informix.
I could make it work by selecting the content of a MySQL table and creating a temp table in Informix with the selected data, but I think in this case it would be too costly.
Is there an optimal way to join MySQL tables with Informix tables?
I faced a similar problem a number of years ago while developing a Rails app that needed to draw data from both an Informix and a MySQL database. What I ended up doing was using of an ORM library that could connect to both databases, thereby abstracting away the fact that the data was coming from two different databases. Not sure if this will end up as a better technique than your proposed temp table solution. A quick google search also brought up this, which might be promising.
This can sometimes be solved in the database management system with a technique called federation. The idea is that you create virtual tables in one of the two systems that makes queries to the other database system on demand.
For both MySQL and MariaDB there is the FederatedX storage engine that unfortunately only works with other MySQL/MariaDB systems. This is a fork of the older, but as far as I know unmaintained, Federated storage engine.
Some might also consider migrating to MariaDB where you can use the CONNECT storage engine which contains an ODBC client.
What I ended up doing is manually (that is, from the php app) keeping in sync the mysql tables with their equivalents in informix, so I didn't need to change older code. This a temporary solution, given that the older system, which is using informix, is going to be replaced.
Lets say we have MySQL server A, where we need to create a 'copy' of table, which is situated on server B.
We don't have federated enabled. Reseting server A would cause much trouble and I believe, we cannot enable federated without reseting. I also believe that it is not enough to enable it on the B server (correct me if I'm wrong in anything)
What other solutions do we have? Is there something enabled by default in mysql server? Any ideas?
You need federated enabled just on server B
You can access a view on A by making a federated table on B
You can do INSERT UPDATE DELETE on federated table
If you need read-only access you can limit the user privileges
BUT! You can't do any aggregate func. on a view which will be federated (ex. COUNT(), MAX(), UNION...) (you can, however it will lag)
Remember to set the KEY's on the federated table you are creating. (or it will lag horr.)
Remember to use ALGORITHM=MERGE on views
Remember to grant acces to USERNAME(from connection string) on server A
example of a federated table on server B:
delimiter $$
CREATE TABLE `schemaName`.`tableName`(
`keyName` VARCHAR(10) NOT NULL,
`key2Name` DATE DEFAULT '2012-01-01',
KEY `keyName` (`keyName`)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8
CONNECTION='mysql://USERNAME:PASSWORD#IPADDRESS:PORTNUMBER/baseSchema/baseTable'
$$
And the view on server A:
CREATE
ALGORITHM = MERGE
DEFINER = `ANOTHERUSERNAME`#`%`
SQL SECURITY DEFINER
VIEW `baseSchema`.`baseTable` AS
SELECT
... AS `keyName`,
... AS `key2Name`
FROM
...
You can't write to a FEDERATED table period ever under any circumstances! You must make a direct DB connection to the server running the database that you have created the FEDERATED table connection to.
I would be pretty angry if you could write to a FEDERATED table now. It has never allowed it for many many years. It would also make the 10 years worth of code I have written a complete waste of my time if that were true.
It is quite handy to use in the instance of making a centralized user database for 100 websites! i.e. A Social Network which is what I use it for...
I have used it since before anyone knew the ENGINE existed. It was there without documentation when I started using it and I had to experiment to even figure out what it could be used for. The ENGINE was always there and had little or no documentation for many years.
The only federated DB tables that I use or have, share network user information. All of my external websites still have to make a database connection to the main server when someone signs up as a new user.
You need two database connectors to use FEDERATED the right way!. One for UPDATE and INSERT etc and the other DB would be for all local queries and JOINS etc.
My network uses two external databases and one local for each website. I use three database connectors.
local connects to Music Hub and Network Hub with separate connectors for all UPDATE and INSERT and everything else JOIN etc just uses the local DB connector!
I hope this helps you understand it a little better :)
I am using MySQL 5.6 and PHP 5.
You have to ask yourself for almost five years, why was there little or no documentation on what it was used for? most people did not even know it existed...
It is used mainly to import query results into your local database! Even with full write access, you would never be able to write to a FEDERATED table! It is not allowed for security reasons and it would be very very slow as you said.
You may correct me if I am wrong but please know that I have been using FEDERATED since before they told anyone it existed.
It takes about 30 seconds to enable FEDERATED and about 30 seconds to reboot the server. In the instance that you are using a VPS, you might not be allowed to have FEDERATED enabled.
Edit your my.cnf file and restart the server...
FEDERATED is no longer slow by the way... Never was when used in the manner I just explained...
Even if I could write to a FEDERATED Table I would not do it. You are FEDERATING two servers by adding a federated table to your local website.
This will slow down depending on how many HOPS away you are from the remote MySQL server. Also be sure and add your IP to the remote server under their cPanel.
IF the websites reside all on the same server and are just separate user accounts and websites with separate IP's there should be Zero Lag.
McLeod and Heimbigner were among the first to define a federated database system in the mid-1980s.
UPDATE: If you upgrade to mariaDB you will have to load federatedX as a plugin. The old federated project will live on but with new eyes and fresh souls working on it. Oracle no longer has a hand in it... It is now called federatedX
Oracle's database link allows user to query on multiple physical databases.
Is there any MySQL equivalent ? Workaround ?
I want to run a join query on two tables , which are in two physical databases. Is it possible in MySQL ?
I can think of four possible workarounds for your scenario:
use fully-qualified-table-names when querying for the external table. MySQL supports the dbname.tablename-syntax to access tables outside the current database scope. This requires that the currently connected user has the appropriate rights to read from the requested table in another physical db.
if your external database is running on a different MySQL server (either on the same machine or via a network connection) you could use replication to constantly update a read-only copy of the remote table. Replication is only possible if you're running two separate MySQL instances.
use the FEDERATED MySQL storage engine to virtually import the table into your current database. This lifts the requirement of giving the current user access rights into the second database as the credentials are given with the CREATE TABLE-statement when using the FEDERATED storage engine. This also works with the databases running on different physical servers or different MySQL instances. I think that this will be the poorest performing option and does have some limitations - more or less important depending on your usage scenario and your requirements.
This is an extension to method 1. Instead of having to specify the fully-qualified-table-names every time you request information from your external table, you simply can create a view inside your current database based on a simple SELECT <<columns>> FROM <<database>>.<<table>>. This resemble the way, the FEDERATED-method works, but is limited to tables on the same MySQL instance.
Personally I'd consider method (4) as the most useful - but the others could also be possible workarounds depending on your requirements.
There's no MySQL equavilent method at the moment, see this post. However as the poster suggest you can do a work-around if the databases are on the same machine, by just adding the database-name in front of the table-name.
Also see this, it's 6 years old, but still not resolved. It's closed and probably not on their todo-list anymore.
I know in SQL Server this is possible using linked servers. Is there some analogous way to do this in mySQL?
Thanks!
You can look into the federated storage engine. I don't know it's stability but it's supposed to support something like this.
Yes, it is possible with the Federated Storage engine, as Olafur Waage states in his answer. This storage engine has to be explicitly invoked (by making the relevant entry in the startup file), but you can set up "shadow" tables locally of the ones you want to query remotely. But beware: the performance may not be that great - in recent tests I did the query executed locally against the remote table (via my federated table) ended up coping the entire contents of the table over the wire and then executing the query, apparently without access to indexes that exist on the remote table (even though they were defined in teh federated table). The result was that a simple query that took about 10 seconds remotely, had to be aborted after about an hour when run against the federated table.