We want to have schemas/database for each functionality on our MySQL Server; so that if load on DB grows; we can move that particular schema to independent server anyday.
How to restrict Joins across Schemas in MySQL ?
Related
I have some questions before implement the following scenario:
I have the Database A (it contains multiple tables with lots of data, and is being queried by multiple clients)
this database contains a users table, which I need to create some triggers, but this database is managed by a partner. We don't have permissions to create triggers.
And the Database B is managed by me, much lighter, the queries are only from one source, and I need to have access to users table data from Database A so I can create triggers and take actions for every update, create or delete in users table from database A.
My most concern is, how can this federated table impact on performance in database A? Database B is not the problem.
Both databases stay in the same geographic location, just different servers.
My goal is to make possible take actions from every transaction in database A users table.
Definitely queries that read federated tables have performance issues.
https://dev.mysql.com/doc/refman/8.0/en/federated-usagenotes.html says:
A FEDERATED table does not support indexes in the usual sense; because access to the table data is handled remotely, it is actually the remote table that makes use of indexes. This means that, for a query that cannot use any indexes and so requires a full table scan, the server fetches all rows from the remote table and filters them locally. This occurs regardless of any WHERE or LIMIT used with this SELECT statement; these clauses are applied locally to the returned rows.
Queries that fail to use indexes can thus cause poor performance and network overload. In addition, since returned rows must be stored in memory, such a query can also lead to the local server swapping, or even hanging.
(emphasis mine)
The reason the federated engine was created was to support applications that need to write to tables at a rate greater than a single server can support. If you are inserting to a table and overwhelming the I/O of that server, you can use a federated table so you can write to a table on a different server.
Reading from federated tables is likely to be worse than reading local tables, and cannot be optimized with indexes.
If you need good performance, you should use replication or a CDC tool, to maintain a real table on server B that you can query as a local table, not a federated table.
Another solution would be to cache the user's table in the client application, so you don't have to read it on every query.
If we want to create mysql databases for cadence. Assuming we want 10 shards for cadence, we should create a set of mysql cadences tables for each shard? If we want 5 machine to create mysql database for 10 shards, how should we do?
Assuming we want 10 shards for cadence, we should create a set of mysql cadences tables for each shard
No. You will only need one set of tables for the whole Cadence cluster.
The sharding mechanism is implemented within Cadence server. Unless you have a sharded MySQL solution, you don't need to worry about anything about sharding when setting up database schema.
If you do have a sharded MySQL, just make sure to use shardID as partition(sharding) key for the table.
Sharding in Cadence is only needed for History service(that's why it's called numHistoryShards in the config).
More reading about the sharding:
https://cadenceworkflow.io/docs/operation-guide/setup/#static-configuration
Typically you will need 2K shards in production if MySQL is the database.
here is some reference that might help you for mysql , postgresql
We are building a MySQL database (Database A) to act as a repository that needs to pull/refresh data from a different database/server. This database (Database B) is not MySQL but rather an ODBC compliant data structure for Sage 100 Accounting.
Database A: MySQl on Server 1
Database B: Sage 100 on Server 2
-- Both servers are on same LAN
I've seen a lot about FEDERATION but it seems it is only mentioned with the same database engines. Since the only substantial equivalent between these two databases is that they are both ODBC compatible, I'm trying to determine if this is still possible using Federation - or any other method.
The goal is to be able to use a MySQL trigger (despite potential performance considerations) to pull data from the Sage 100 database as needed to update the MySQL db to keep records in sync.
Is this possible with federation? If not, what other options do I have?
I am looking to have one main database with global data such us users & subscriptions. Additionally, to that, each subscription will have its own database, i refer to this type of databases as children.
Databases will be located on different servers, those servers may change from time to time. Due to this child databases are not able to utilize (as far as I am aware) the benefit of foreign keys on data from the global database. i.e. linking a "tool" in the "tools" table, which has column user_id = 12, with the user in the global database.
The question is is it ok for me to include columns, in child databases, that will store ids referencing data in the global database? Is there facilities that I can put in place to recreate what foreign keys offer?
I am running MySQL 5.7, InnoDB engine. The system runs on Laravel 5.2.
I have a relatively light query that needs information from a local MySQL table along with another MySQL table which is stored on a physically separate machine (on the same network). I'm keen to avoid setting up replication just to facilitate this light query that only needs executed once a day.
Is there any way that I can join with a table on a remote machine using one query? Or run a SELECT INTO into a local table.
Notes
I'm using C# & .NET 4.
This can be done by using the FEDERATED storage engine for the remote table. Find out more.