In virt-manager I see that my default storage pool is almost full.
When I create a new storage pool, it doesn't help, because it has the same usage percentage as the default.
As you see, I don't understand it. What must I do?
Thanks,
Eric J.
You can refer to Fedora's documentation for creating a new storage pool. It's pretty straightforward and simple.
http://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/sect-partbased-storage-pool.html
Related
I have an PHP-based API that runs on shared hosting and uses MySQL. I've been doing reading on InnoDB vs MyISAM and wanted to paste some specific things about my API's database to make sure it makes sense to move on to InnoDB. MyISAM was set by default for these tables, so I didn't deliberately pick that database engine.
My queries are a little more writes than reads (70% writes I'd say). Reads/lookups are always by a "foreign key" (userid) (I understand MyISAM doesn't have these constraints) but might be good to know if I move since I could take advantage of that.
I don't do full text searches
My data is important to me, and I recently learned MyISAM has a risk of losing data? A few times in the past I've lost some data and just assumed it was my user's fault in how they interacted with the API. Perhaps not? I am confused about how anyone would be ok with losing data and thus choosing MyISAM so perhaps I don't understand MyISAM enough.
I'm on a shared host and they confirmed I don't have access to change settings in my.cnf, change buffers, threading, concurrency settings, etc.
I will probably switch to DigitalOcean or AWS in the future
My hosting company uses MySQL Version is 14.14 Distribution: 5.6.34
Based on these factors, my instinct is to switch all my tables to InnoDB and at least see if there are problems. If I hit an issue, I can just run the same statement but swap InnoDB with MyISAM to revert back.
Thanks so much.
Short answer: YES! MyISAM was the original format of MySQL, but many years ago InnoDB has been preferred for many reasons. On high-level picture, your app will better perform as InnoDB has a better lock management.
You can find here a longer answer to your question Should I change my DB from MyISAM to InnoDB? (AWS notification) and the following 2 articles covering migration from MyISAM to InnoDB:
https://dba.stackexchange.com/questions/167842/can-converting-myisam-to-innodb-cause-problems
https://kinsta.com/knowledgebase/convert-myisam-to-innodb/
Is there any way to tell Hibernate use MySql Memory Storage Engine?
Thanks.
Edit: I found Memory Storage Engine does not support all features of a regular Store Engine like InnoDB, etc. So it may be seemed logical that there is no option for it.
There should be a properties file where you can put your URL to MySQL
#hibernate.dialect org.hibernate.dialect.MySQLDialect
#hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect
#hibernate.dialect org.hibernate.dialect.MySQLMyISAMDialect
#hibernate.connection.driver_class com.mysql.jdbc.Driver
#hibernate.connection.url jdbc:mysql:///mysqlURL
#hibernate.connection.username
#hibernate.connection.password
But be aware of this
When using the MyISAM storage engine, MySQL uses extremely fast table locking that allows multiple
readers or a single writer. The biggest problem with this storage engine occurs when you have a steady
stream of mixed updates and slow selects on a single table. If this is a problem for certain tables, you can
use another storage engine for them.
The storage engine used by mySQL is declared when you create your tables. Use the qualifier ENGINE=MEMORY at the end of your CREATE TABLE DDL. Then use it like any other table.
But, of course, remember that if your mySQL server bounces for any reason, all rows will be gone from that MEMORY table when it comes back.
Why do you want in-memory storage?
My personal use case scenario for such a setup is testing.
Think about using h2, hsql or derby. AFAIK they all provide in-memory storage. And if you consistently use Hibernate, it should make no difference which database runs in the background -- at least not from a development standpoint.
One of Percona Server with XtraDB's main benefits is enhanced scalability over regular MySQL. Does anyone know how the data stored on disk for a given table compares between Percona/XtraDB and MySQL, i.e. is the same table stored in each system bigger, smaller or the same in Percona/XtraDB? I have a feeling it's the same, but would like to know for certain and haven't been able to find any relevant info.
I've only started looking at Percona/XtraDB, so trying to gather some info on it, thanks.
It's exactly the same (unless you explicitly enable extra features).
Source: I work for Percona.
Since XtraDB is an enhanced version of InnoDB, I would expect it to have a larger size. Never used XtraDB but since its a fork of InnoDB, it'd expect it to be such.
Btw what is regular MySQL ? MyISAM storage engine ?
I've noticed that mysql (5.0.60) often freezes for up to minutes at a time under load, during which time the server is completely non-responsive. I've been able to isolate this to only happening when innotop shows the main thread state as "making checkpoint".
What is the server actually doing at this point?
Checkpointing is when the database server commits all in-memory changes to disk.
This one answers your question and also has some solutions to your problems:
As you might know Innodb storage engines uses Fuzzy Checkpointing technique as part of it recovery strategy. It is very nice approach which means database never needs to “stall” to perform total modified pages flush but instead flushing of dirty pages happens gradually in small chunks so database load is very even.
http://www.mysqlperformanceblog.com/2006/05/10/innodb-fuzzy-checkpointing-woes/
I thought I'd expand on Pradeep's comment:
InnoDB's (default) fuzzy checkpointing can get behind on flushing dirty pages to disk very easily*. This can create a problem when the end of a log file is approached, and a checkpoint is forced.
This is a well known InnoDB problem - and there are third party patches available to help. In XtraDB, innodb_adaptive_checkpoint speeds up the page flushing as the end becomes nearer:
http://www.percona.com/docs/wiki/percona-xtradb:patch:innodb_io
The explanation why is a little more complex. The main thread has some hardcoded constants to determine if the server is to "busy" to flush pages, such as if more than 100 IO operations/second have already occurred ("IOPS"). 100 IOPS is of course about the number of operations a single 7200RPM disk can complete, and might not make sense if your server has RAID, and multiple disks. XtraDB also has the option for describing innodb_io_capacity.
A similar patch has been released by InnoBase in the 1.0.4 Plugin (not in an official MySQL release yet).
I want to load a MYSQL-database into the RAM of my computer, is there a way to do this? I am running this database under Linux. Also, if this is possible, is there a good way to make backups, because if the computer is unexpectedly shut down, I would lose all my data.
If you buffer pool is big enough, you data is -- effectively -- an in-memory database with a disk backup copy. Don't fool around with RAM databases, simply make the buffer pool size as large as you can make it.
Read this:
http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_buffer_pool_size
Yes, you can use the MEMORY engine. As far as backups, it's your call. You never said, e.g. how often you want to store to disk. But you can use traditional MySQL replication or your own solution.
absolutely, for example under linux you can mount your database in a tmpfs
If you're using innodb tables then I recommend adjusting the buffer pool size like S.Lott suggested above. Make it 110% or so of your database size if you have the ram.
If your database is > 50mb you'll also want to look at increasing the innodb_log_file_size. See http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_log_file_size Perhaps to around 25 - 50% of your buffer pool size, but 1gb max.
The innodb_log_file_size is a bit tricky to adjust. You need to shut the db down, move the current log files into a backup location, and let mysql recreate them when it's restarted (i.e. after you've changed the values in my.cnf). Google it and you'll find some answers.