I've heard a few folks mention that mariadb schema updates are or can be lockless. Other than an anonymous mention in the comments of this page, I can't find any references. We have a very large table we're going to update, and were wondering if others had experience with this.
We're going to test this soon, and I'll report back, but I was hoping to find more official sources for this.
MariaDB does support ALTER ONLINE, but it's not fully implemented, or well-documented on the site yet (https://mariadb.com/kb/en/alter-table/). It's been present since MariaDB 5.3, but is still in the process of being ported in MariaDB 10. So it depends on what version you're running, and you'd need to check to see whether it could handle your situation.
Related
What happens in Grails, when you update your model, and deploy it to your web server? Does the existing data get overwritten?
If your model is changed you need to upgrade your db, you can use this plugin.
Make sure you change you setting from create-drop to update.
There are a couple of good guides you can look at, here is a good one.
Good luck!
The behavior is defined in the GORM configuration
Basically, the default for development is drop-create, which erase all the content, and recreate tables.
On more stable releases, update might be a good setting knowing that Hibernate prefer to fails that conflict.
As always, I would recommend making a backup of the DB before performing such operation on pre-production and production systems.
Most (if not all) of existing migration tools think that migration history is linear. So when you create new migration, you get version 42 or whatever, and then everybody can update to this version after receiving your changes.
The problem is that if you are using DVCS, two people could have version 42 in the same time. Which means that conflict resolving will become sufficiently non-trivial to be painful. :)
So my question is - should I roll my own system or is there anything in the wild? Preferably simple, friendly to *nix. I'm planning to use this mostly with mysql and postgresql.
In Rails, the way this gets handled is by appending the date to the beginning of the file, in the form of YYYYMMDDHHMMSS_migration_descriptor.rb.
It then keeps track of which migrations have been applied in a table, by keeping track of the version numbers. This allows you to run migrations on a table with a "lower" version number than the most recent change, thus greatly simplifying DVCS problems.
You might not be using Rails, but I think the way they solve this problem is pretty nice. You can read more about Rails migrations on the API docs, or on the Rails guides.
Does anyone know if it's good solution to use SQLite in multi-thread environment.
I want to replace SQL Server with more simple and built-in database as there is no need to feed such big server DB. The supposed max size of DB would be 4 gigabyte after 4-5 years of usage. Is it normal for built-in DB? Could it affect performance?
It depends on the type of queries you would use. If the queries are simple selects with plain joins, then SQLite could do fine but I think you would still be better off with e. g. Firebird 2.5 when the stable release gets out (RC3 is available now). You would have somewhat richer SQL to work with. I don't know how much bulk loads are important for you, but neither SQLite nor Firebird are very strong in this area. If you need good bulk insert performance and low cost, then you should look at PostgreSQL or MySQL. There is also a very interesting looking database I happened to stumble upon recently called CUBRID. I have only installed it so far, so I can't tell how good or bad it is but it certainly seems worth a look.
You might also want to look at this wikipedia article:
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
I don't know which distro you're talking about here. I've only used SQLite.NET and I know it works well on multithreaded applications.
It can also be deployed on client-server systems so you need not worry at all.
Considering Vinko's statement of 'real' databases, you can ignore him. SQLite is really worth it's salt.
If you're working with .NET, you might find this link useful:
http://sqlite.phxsoftware.com
According to the documentation SQLite is thread safe but there are caveats.
You can use SQLite in a multithreaded environment, but if and only if you build a special version of it (and find out if the library you'll be using it supports it and tweak it if it doesn't.) So, assuming your library supports multithreaded SQLite, if you really need a high level of concurrency to the database you may prefer to use a 'real' database. Be it MSSQL or any other falls out of the scope of the question.
Consider MySQL and SQL Server Express, for example.
If your concurrency level is low, SQLite can cope with it.
I would also suggest you to take a look at the CUBRID database. It has nice optimizations for Web applications and it is easy to learn.
Can someone recommend a great IDE/Database Developer Tool for Postgres 8.4. We are currently using EMS SQL Manager but it has so many bugs and shortcomings that its getting on my nerves. I reported the bugs to EMS but they have not been fixed yet.
I wonder what do people use for PostgresSQL development? Windows/Linux, commercial/free, standalone/eclipse plug-in, it does not matter as much. I just want a reliable tool that works and does not blow up in my face.
On PostgreSQL DB we do and would like to have IDE support for.
Tables, views, indexes, triggers
SQL, plpgsql, and python procedures that return single values, set of values or tables
SQL query and performance monitoring
DB role management
Good transaction support straight from GUI as well as support for BEGIN, COMMIT, etc
Any recommendations are welcome.
Edit: After many months we are still using EMS SQL Manager. I got used to certain shortcomings, some bug were fixed. I tried every possible PostgreSQL management program I could get my hands on and still in my opinion EMS SQL Manager is still the best.
pgAdmin is a popular one. It's free, and it runs on Windows and Linux. It's been a while since I have used it but I found it to be quite stable. Wasn't fond of the procedure code editor - it worked, I just didn't like it (but now I can't remember why, it was probably a minor thing).
Lightning Admin, commercial, postgreSQL and mysql, $50. The developer is very pro postgreSQL.
http://lightningadmin.com/
Wondering if anyone has gotten the infamous "database is locked" error from Trac and how you solved it. It is starting to occur more and more often for us. Will we really have to bite the bullet and migrate to a different DB backend, or is there another way?
See these two Trac bug entries for more info:
http://trac.edgewall.org/ticket/3446
http://trac.edgewall.org/ticket/3503
Edit 1 Thanks for the answer and the recommendation, which seems to confirm our suspicion that migrating to PostgreSQL seems to be the best option. The SQLite to PostgreSQL script is here: http://trac-hacks.org/wiki/SqliteToPgScript Here goes nothing...
Edit 2 (solved) The migration went pretty smooth and I expect we won't be seeing the locks any more. The speed isn't noticeably better as far as I can tell, but at least the locks are gone. Thanks!
That's a problem with the current SQLite adapter. There are scripts to migrate to postgres and I can really recommend that, postgres is a lot speeder for trac.
They just fixed this on Sept 10, and the fix will be in 0.11.6.
http://trac.edgewall.org/ticket/3446#comment:39
I don't think this is 100% fixed just yet. We experience this error a couple dozen times a day. In our case, we have 30+ people updating Trac constantly as we use it for tracking pretty much everything, and not just bugs. From ticket #3446:
Quite obviously, this is [...] due to
our database access patterns... which
currently limit our concurrency to at
most one write access each few seconds