The background:
I have an old MariaDB 5.5 installation which has all configuration defaults, databases, tables and columns set to utf8/utf8_general_ci. I want to change everything to utf8mb4/utf8mb4_unicode_ci.
My question:
Should I also update the "mysql" system table?
Looking at it, that schema appears to be utf8/utf8_general_ci. I don't know if that's because the server was initialised with that as a default configuration, or because that's what it should be. Does it even matter?
The side question:
If I decide to dump all databases in an effort to enable the files_per_table option and reimport all the databases, should I include the "mysql" system database in this endeavour?
Related
I had a MySql database named (say) "dbname" on my 10.1.13-MariaDB, and used the 'rename' operation in my PHP My Admin 4.5.1 to rename it to "dbName". Unfortunately this deleted the database.
I presume this is because I am running xampp on Windows, and this always creates databases with lower case characters, so the rename created a new database named "dbName", copied the old "dbname" database, then deleted "dbname", which unfortunately translated to deleting the NEW database due to the 'always use lower case for db names' rule.
I understand the cause of this is, at its root, the case insensitivity of Windows, and I have had trouble with this when referring to databases as "dbName" on Linux systems, but when I migrate the database to a Windows system, I need to refer to the database as "dbname" in my php mysqli connections.
However, my question is: can I get the database back! Is there a secret feature that I don't know about where phpmyadmin's rename feature actually MOVES stuff it deletes to somewhere?
I anticipate several comments about the necessity of backups, and I am glad to provide people with the opportunity to remind the community of the importance of frequent backups.
This seems to be a problem with how phpMyAdmin handles renaming a table; I've opened a bug report at https://github.com/phpmyadmin/phpmyadmin/issues/13800 and it's already been fixed for inclusion in the next version of phpMyAdmin later this month. Unfortunately, there's no recycle bin or any sort of safety measure here. If you have filesystem-level backups, you might be able to replace your entire MySQL data directory in order to regain access to your database, but unless I'm misunderstanding something it's no longer in MySQL/MariaDB.
On my AWS RDS MySQL instance I have some databases I didn't explicitly create there (and have never seen on my local MySQL databases, or on other hosted databases I've worked with) and wonder what they are (and what I can do about them):
information_schema
mysql
performance_schema
innodb
The first three are filled with data that I don't understand (and are listed separately in my MySQL tools; e.g. I have no ability to control privileges for them separately), while the last is empty. Can I delete the innodb? What are the others (I assume I should leave them alone)?
Forgive what may turn out to be a naive MySQL or AWS question; I'm fairly new to both.
These are all normal.
Every MySQL installation has the mysql and information_schema databases. If you can't see them, then either you either don't have permission to see them, or whatever you're using to connect to the MySQL server is hiding them from you. Most newer MySQL installations also have performance_schema.
The innodb database on RDS isn't really a database, but it shows up in the list because of the way the design of RDS interacts with MySQL server's internal concept that each directory inside that datadir is assumed to be a database. Files that InnoDB uses internally are stored there, even though the "database" itself appears to be empty. Just disregard it.
The mysql database contains tables used internally by MySQL, including the grant tables and time zone tables, and some DBA tools in the form of stored procedures that are specific to RDS, which are required due to the restricted access that even the administrator account has to an RDS instance, when compared to a standalone MySQL server.
http://dev.mysql.com/doc/refman/5.6/en/information-schema.html
http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html
I have this situation. The site that I'm working with has MySQL configured without InnoDB. My Ubuntu localhost has MySQL server running with InnoDB.
Question: If I export the MySQL database of the remote site and import it to my local Ubuntu MySQL , will that work without any issues? Supposing I export it using the mysql command line mysqldump and restore it via command line too. The database is a bit large so I need to check first whether this will work.
I'm planning to import it locally so I can test the site for the functionalities needed. Please let me know if this plan will work. Thanks :)
First if mysqldump have engine=InnoDB statement in CREATE TABLE block, Then it could possible to import failure if Local MySQL is not configured to use InnoDB (I personally think InnoDB is always available, However it could be non default engine).
After successful import, It may be automatically converted to default MyISAM Engine. So All foreign keys and InnoDB related objects will not imported in this case. Now if your application very much depend on DB based Foreign keys mechanism, Then it can broke. Otherwise things should work like before.
Personally I imported InnoDB databases before end they automatically converted to MyISAM. Application work seemlessly as That manage constraints on Application side (in MVC Models).
Is it possible to change the default collation of SQL Server 2008 without having to reinstall the whole package ? It has to be Case Sensisitve by default - the application server I have checks this as a pre condition to installing and creating a database.
Yes it is, but it is not for the faint of heart...
From http://msdn.microsoft.com/en-us/library/ms179254.aspx:
Changing the default collation for an instance of SQL Server can be a
complex operation and involves the following steps: Make sure you
have all the information or scripts needed to re-create your user
databases and all the objects in them.
Export all your data using a tool such as the bcp Utility. For more
information, see Importing and Exporting Bulk Data.
Drop all the user databases.
Rebuild the master database specifying the new collation in the
SQLCOLLATION property of the setup command. For example:
Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=InstanceName
/SQLSYSADMINACCOUNTS=accounts /[ SAPWD= StrongPassword ]
/SQLCOLLATION=CollationName
For more information, see Rebuilding System Databases.
Create all the databases and all the objects in them.
Import all your data.
If you can get away with just changing the default collation of the database(s) specific for the application, you may want to do that...
I am moving all my websites to one server, and I was wondering if it is okay to leave out the information_schema because I have multiple different ones from different servers.
information_schema is a virtual db used for querying database metadata.
You don't have to move it, the data there are generated automatically from your other databases.
if you dump your tables structure and data (export in phpmyadmin) you can easylie import that data in an other mysqldb. and u don't need the information_shema for it.
be sure to have same encoding and mysql versions.
Yes. In fact, the mysqldump tool often used for backing up databases ignores INFORMATION_SCHEMA. When you restore the database on the new server, MySQL will update the INFORMATION_SCHEMA on that server.