So a friend of mine asked me to help him configure an automatic replication of a table on his MariaDB database to another table that's supposed to be an exact copy of the source/primary table.
The databases are on the same server. MariaDB version 10.2.44. The databases are on a cPanel managed webserver run by a webhost. We are accessing the databases using HeidiSQL, which is what I'm hoping I can use to configure everything.
Upon lots of googling, this is the article I suspect makes the most sense for what we want to do, but it doesn't look like this is automatic to any extent: https://mariadb.com/kb/en/setting-up-replication/
Is this the best way to do what we're trying to do? Is there a better way? Any suggestions?
Thanks!
Like #ysth said, in this case, triggers can be used.
When creating a trigger that "works between different databases", you need to specify the database on the trigger name. So for example:
CREATE TRIGGER database_name.trigger_name
Otherwise you'll get an "Out of schema" error.
The database you need to specify is the one where the "listener" is located. Basically, the place where the condition for the trigger is being checked.
Related
I have two containers in my meteor app on galaxy servers. I have some background jobs that I want to be executing only on a single container to avoid duplication.
What's the easiest way to achieve this? Is there some procId or the like that I can retrieve during runtime?
If the two servers have their own settings files, you could use a setting to nominate one of the servers as the one that does the background jobs.
There is a package called node-cron that can be used for setting up regular jobs https://www.npmjs.com/package/node-cron
Use a Meteor.startup method to look at the settings file, and if it is the designated server, it can schedule the jobs for itself.
Another technique is to work out the ID of each server, and have database entry containing the id of the nominated server.
On checking further, https://github.com/percolatestudio/meteor-synced-cron supports multiple servers, which should do what you need :)
I was thinking about this more... one solution (which I'm kind of borrowing from meteor-migrations) is to make a simple database collection/entry that holds a startupCodeHasRun flag. Then in a Meteor.startup() block you can check if the flag has been set, if not, set the flag and run the code. This would cause the code to only be run once on only one of your containers that share the same database.
The gotcha is you would have to reset this flag manually before redeploying or else the code would never be run again on redeploy.
Not an ideal solution but could work. This is the same way the above database migrations package works in a multi-container environment. And since it's a one-time database migration, you don't have to worry about redeploy.
I am trying flyway for first time, evaluating how it will fit into our project.
Trying to understand how a Failed Scenario will work
Naturally, what i did next was, modified the sql script, and re tried running, but got checksum error
Have three Ques here
So I guess the only way out is ... need to make a 1.2 with correct format or manually modify 'schema_version' table. Right , or am i missing something?
Wondering how will such a scenario work in case if this script is called from continuous integration tools (Jenkins or Bamboo). Manual Intervention will be needed.
Not sure if some other tool like Liquibase will behave in a different (better) manner
In that situation I think you should use "flyway repair" rather the "flyway migrate"
https://flywaydb.org/documentation/command/repair
One thing from your post that is not clear is was the script you ran a single DDL statement or a number of statements, of which one or more failed?. The reason for asking is that flyway records the results of a migration, but does not itself clean up 'script errors'. Depending on the database you are using this could be done by running the DDL statements within a transaction.
Liquibased operates with a much tighter connection to the database as it directly interacts with the DDL that can be expressed in a range of different formats. As such it has a much tighter control over the management of DDL deployment.
Upstream insists on manual rolling back of failed migration and re-applying it again. There is no "skip" command.
But you can manually fix and complete failed migration and manually change "schema_version"."success" to 1.
I am creating web service in zend framework which uses DynamoDB. So I installed DynamoDB in local. But it's not easy to use. Even for inserting data and update any data for testing for purpose I have to write a script.
Is there any DynamoDB client available for MAC ? In which we can insert/update/delete data from UI.
EDIT
Doubts
1) Do I have to run a SQL to see table data? I thought there would be GUI for this.
2) I am not able to use where clause in SQL. What if I want to see one or two records from all? Is there a way to use conditions in this?
3) All fields of a row is not visible and I am not able to scroll it horizontally ?
YES! I've finally found a solution after struggling with this myself:
Run your local dynamodb jar with the following command java -jar DynamoDBLocal.jar -dbPath . [this will create a file in whatever directory the Dynamo jar is located in].
Download SQLite Database Browser and extract/install it.
Start SQLite Database Browser
Navigate to "Open Database" from the file menu
Navigate to the directory from 1. Select the file [in this case, ****_us-east-1]
You should then see the database contents!!
Hope this helps - it's been frustrating me no end!
!! EDIT !! - in response to original question edit.
Doubts
1) Do I have to run a SQL to see table data? I thought there would be
GUI for this.
2) I am not able to use where clause in SQL. What if I want to see one
or two records from all? Is there a way to use conditions in this?
3) All fields of a row is not visible and I am not able to scroll it
horizontally ?
Yes - you can do a simple "select" statement, for instance in my examples: "SELECT * FROM tweet_item" returns me the following screenshot:
Seemingly inadvertanyl - whilst I couldn't get the direct SELECT * FROM XX WHERE XX to work, the like statement does. For instance SELECT * FROM tweet_item where tweet_item.hashKey like "%425665354447462400%" returns me the tweet with tweet_id [my hashKey] of 425665354447462400:
Strange - I seem to be able to scroll quite happily [although it is Windows not Mac]. It also automatically tries to re-size the outer frame, too.
I ran into this problem and found a relatively new solution : https://github.com/aaronshaf/dynamodb-admin
It has provision for GET/POST/PUT/DELETE.
Although its a paid product, which is a bummer, RazorSQL now supports DynamoDB as well, and does let you change the AWS endpoint to point to a local installation.
The mac version (with a free trial) is available here:
http://razorsql.com/download_mac.html
Here is a very useful ui tool https://github.com/YoyaTeam/dynamodb-manager，It supports almost all data operations。
For Eclipse users:
Amazon provides AWS Toolkit for Eclipse IDE. It can view local and cloud databases. Also if you are using different regions, it has ability to choose from different regions.
You can create attributes, add keys etc..
For installation follow this link: http://docs.aws.amazon.com/toolkit-for-eclipse/v1/user-guide/getting-started.html
Dynobase is new DynamoDB GUI Client which also lets you browse and manipulate local DynamoDB instances: https://dynobase.dev/dynamodb-local-admin-gui/
Unfortunately, it's paid but there's free 7-days trial, works on Mac, Windows and Linux: https://dynobase.dev/
We are thinking of moving some of the 'hard coded' settings out of our windows forms application and storing them in the sql database in a table called App_Settings. The reason for this is we have values currently hard coded into appsettings and app.config which can change over time, and it is much easier and faster to update the values in a database table than it is to update, build and deploy the app over three servers.
Please can someone advise on this, and also how can we load the settings into the app and then have them readily available in any class?
Cheers
Richard
Have a look at this similar thread: Resources/App.config or Database where is the best place to application strings
When you want to store settings in the database i would implement the class as Singleton or at least as a Class with only static/shared members and a factory method(getAppSettings)which returns that single/static instance. So you could access your settings from everywhere and it is only initialized once.
Why don't you use something like YAML to save these settings? It would be easy to create a form to edit and save these settings in a file, instead of a db (which would add more maintainance problems).
Otherwise, I would suggest to use something like NHibernate to use a database, and SQLLite as the db server.
Also, note that if you are updating these settings, I would not say that these are App_Settings, since App_Settings aren't usually modifyable without
Help this helps,
Pietro
The scenario is this. I have a SQL Server database online that I am demoing an application. During development, I have added extra fields, modified field types, changed keys and added some new tables locally.
What's the best way for me to update the online database with the new structure and not lose the data? The database is a SQL Server 2005 one.
Download a trial of Red Gate SQL Compare, compare your two servers and you are done. If you do this often, it is well worth the $400, or get one of their bundles for a better bang for the buck.
And I do not work for Red Gate, just a happy customer!
Write update scripts to modify your live database structure to the new structure, as well as inserting any data which is required.
You may find it necessary to use temporary tables to do this.
It's probably best if you test this process on a test environment, before running the scripts on the live environment.
Depending on what exactly you've done you may be able to get away with alter statements, though from the sounds of it (removing keys and whatnot) you're doing some heavy lifting that may make that a less-than-ideal solution. You should probably look into creating a maintenance plan or, better yet, a SQL Server Integration Services project in Visual Studio. You should be able to migrate the data in the existing database to a new one using those tools.
This probably isn't of huge help retrospectively, but I always script all structural DB changes to my development database and then using a version number to determine the current version of the DB I can run the required scripts on the live DB, hence bringing it back in line at the same time as the new code is uploaded.
This also works for any content changes, for instance if the change in the underlying structure has an effect on the conent stored you can also write scripts to migrate the data accordingly.
Make a copy of the existing database to copy from.
Make another copy and alter it to your new schema. save DDL for reuse.
Write queries that copy data from #1 to #2. Save the queries for reuse.
Check the results.
Repeat until done.