MySQL is one of the most popular relational database management systems in use today, powering many popular websites and applications. To get the best performance, you need to optimize the MySQL database.
innodb_buffer_pool_size – Increase the buffer pool size. The buffer pool is where MySQL stores data and indexes in memory, so increasing its size can improve performance. A good rule of thumb is to set the buffer pool size to 80-90% of available memory.
nnodb_buffer_pool_instances – Increase the innodb_buffer_pool_instances. This will help to reduce contention and increase scalability.
innodb_log_file_size – Increase the innodb_log_file_size. This controls the size of the InnoDB redo logs, which are used to recover the database in case of a crash.
query_cache_size – Increase the query_cache_size. This cache stores the results of SELECT statements, so increasing its size can improve performance for frequently-run queries.
Tune the sort_buffer_size, read_buffer_size and read_rnd_buffer_size based on your workload.
Optimize your database schema by creating indexes on columns that are frequently searched.
Optimize MariaDB
Edit file
vi /etc/mysql/mariadb.conf.d/50-server.cnf
Find
[mysqld]
On this section, you will see “#skip-external-locking”, add below.
Having more innodb_buffer_pool_size, make MySQL act like an in memory database.
innodb_buffer_pool_instances divide buffer pool into smaller instances. It is better use 1 GB per instance.
To see current innodb_buffer_pool values, run
show variables like '%innodb_buffer_pool%';
innodb_flush_log_at_trx_commit
Controls the balance between strict ACID compliance for commit operations and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. You can achieve better performance by changing the default value but then you can lose transactions in a crash.
The default setting of 1 is required for full ACID compliance. Logs are written and flushed to disk at each transaction commit.
With a setting of 0, logs are written and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash.
With a setting of 2, logs are written after each transaction commit and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash.
If you can afford to lose 1 second of data, setting value of innodb_flush_log_at_trx_commit to 2 will improve performance. For most web applications, this works fine.
CREATE USER 'USERNAME-HERE'@'localhost' IDENTIFIED BY 'PASSWORD_HERE';
GRANT ALL PRIVILEGES ON DB_NAME_HERE.* TO 'USERNAME-HERE'@'localhost';
FLUSH PRIVILEGES;
To allow remote access, run
CREATE USER 'USERNAME-HERE'@'%' IDENTIFIED BY 'PASSWORD_HERE';
GRANT ALL PRIVILEGES ON DB_NAME_HERE.* TO 'USERNAME-HERE'@'%';
FLUSH PRIVILEGES;
To allow a user to create another user
GRANT GRANT OPTION ON *.* TO 'USERNAME-HERE'@'localhost';
Now this user will be able to create new users.
Create a user with root privilages
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' IDENTIFIED BY 'MYSQL_PASSWORD' WITH GRANT OPTION;
GRANT PROXY ON ''@'' TO 'admin'@'localhost' WITH GRANT OPTION;
For MySQL 8
CREATE USER 'admin'@'%' IDENTIFIED BY 'AEs308SuEtT0Hs';
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'%' WITH GRANT OPTION;
[root@3blogger log]# cat mysqld.log
170102 21:34:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2017-01-02 21:34:02 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2017-01-02 21:34:02 0 [Note] /usr/sbin/mysqld (mysqld 5.6.24-72.2) starting as process 8048 ...
2017-01-02 21:34:02 8048 [Note] Plugin 'FEDERATED' is disabled.
2017-01-02 21:34:02 8048 [Note] InnoDB: Using atomics to ref count buffer pool pages
2017-01-02 21:34:02 8048 [Note] InnoDB: The InnoDB memory heap is disabled
2017-01-02 21:34:02 8048 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-01-02 21:34:02 8048 [Note] InnoDB: Memory barrier is not used
2017-01-02 21:34:02 8048 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-01-02 21:34:02 8048 [Note] InnoDB: Using Linux native AIO
2017-01-02 21:34:02 8048 [Note] InnoDB: Using CPU crc32 instructions
2017-01-02 21:34:02 8048 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2017-01-02 21:34:02 8048 [Note] InnoDB: Completed initialization of buffer pool
2017-01-02 21:34:02 8048 [Note] InnoDB: Highest supported file format is Barracuda.
2017-01-02 21:34:02 8048 [Note] InnoDB: Log scan progressed past the checkpoint lsn 644142666552
2017-01-02 21:34:02 8048 [Note] InnoDB: Database was not shutdown normally!
2017-01-02 21:34:02 8048 [Note] InnoDB: Starting crash recovery.
2017-01-02 21:34:02 8048 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-01-02 21:34:02 8048 [ERROR] InnoDB: space header page consists of zero bytes in tablespace ./3blogger/wp_wfNet404s.ibd (table 3blogger/wp_wfNet404s)
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size:1024 Pages to analyze:64
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size: 1024, Possible space_id count:0
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size:2048 Pages to analyze:32
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size: 2048, Possible space_id count:0
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size:4096 Pages to analyze:16
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size: 4096, Possible space_id count:0
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size:8192 Pages to analyze:8
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size: 8192, Possible space_id count:0
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size:16384 Pages to analyze:4
2017-01-02 21:34:02 8048 [Note] InnoDB: Page size: 16384, Possible space_id count:0
2017-01-02 21:34:02 7fcef14617e0 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./3blogger/wp_wfNet404s.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
170102 21:34:02 mysqld_safe mysqld from pid file /var/lib/mysql/3blogger.3blogger.com.pid ended
[root@3blogger log]#
This was because the server used InnoDB database engine and my.cnf was not configured properly.