version:10.0.33-MariaDB
trying to perform an ALTER TABLE and it's running out of diskspace during the rebuild, currently using /tmp from ##tmpdir. I'm trying to set ##innodb_tmpdir from NULL to another directory and it continuously fails with the below error:
MariaDB [(none)]> set ##innodb_tmpdir = '/tmp/inno_tmpdir';
ERROR 1231 (42000): Variable 'innodb_tmpdir' can't be set to the value of '/tmp/inno_tmpdir'
MariaDB [(none)]> show warnings\G
*************************** 1. row ***************************
Level: Warning
Code: 1210
Message: InnoDB: Server doesn't have permission in the given location.
*************************** 2. row ***************************
Level: Error
Code: 1231
Message: Variable 'innodb_tmpdir' can't be set to the value of '/tmp/inno_tmpdir'
2 rows in set (0.00 sec)
I've given the directory full permissions to mysql.
[root#host tmp]# ls -lrt | grep inno_tmpdir
drwxrwxrwx. 2 mysql mysql 4096 Oct 16 12:15 inno_tmpdir
the odd part is that I can set ##innodb_tmpdir /tmp (which ##tmpdir is set to ) /usr/tmp or /var/tmp
MariaDB [(none)]> set ##innodb_tmpdir = '/var/tmp';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> set ##innodb_tmpdir = '/usr/tmp';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> set ##innodb_tmpdir = '/tmp';
Query OK, 0 rows affected (0.00 sec)
I had a similar problem but with MySQL 5.6.49.
What I did - it's just added full permission to the new temp directory:
chmod 777 /tmp/inno_tmpdir
and then I was able to set innodb_tmpdir = '/tmp/inno_tmpdir'
innodb_tmpdir is looked at startup, unlike some other (like innodb_data_home_dir, innodb_undo_directory)
To search for tablespaces into other directories, you must add them (comma separated in Linux, I believe) to innodb_directories.
Related
When I tried to run pgbench, during the initialization phase, ran into an error that “This ALTER TABLE command is not yet supported.” See details below:
$ pgbench -i -U postgres -d postgres -p 5433 -h 127.0.0.1
NOTICE: table "pgbench_branches" does not exist, skipping
WARNING: Storage parameter fillfactor is unsupported, ignoring
NOTICE: table "pgbench_tellers" does not exist, skipping
WARNING: Storage parameter fillfactor is unsupported, ignoring
NOTICE: table "pgbench_accounts" does not exist, skipping
WARNING: Storage parameter fillfactor is unsupported, ignoring
NOTICE: table "pgbench_history" does not exist, skipping
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
**set primary key...
ERROR: This ALTER TABLE command is not yet supported**.
In YugaByte DB, currently, the PRIMARY KEY clause has to be specified as part of the CREATE TABLE statement, and cannot be added after the fact via an ALTER TABLE command.
We have made a recent change to the "pgbench" utility (that's bundled as part of the YugaByte DB distribution) to specify the PRIMARY KEY as part of the CREATE TABLE statement itself.
The relevant issue is:
https://github.com/YugaByte/yugabyte-db/issues/1774
The relevant commit:
https://github.com/YugaByte/yugabyte-db/commit/35b79bc35eede9907d917d72e516350a4f6bd281
I want to allocate more memory to my MariaDB server but I am having difficulties in locating the right my.cnf file.
Basically I want to edit the innodb_buffer_pool_size
This is the content of the my.cnf file in /etc/my.cnf
[mysqld]
bind-address = ::
skip_name_resolve
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
#
# include all files from the config directory
!includedir /etc/my.cnf.d
So I proceeded to check the files in /etc/my.cnf.d for the innodb_buffer_pool_size value, but most of the files are almost empty.
Should I just add the string with the value that I prefer? Or am I looking in the wrong place?
Using Plesk 17.5.3 #18 CentOS 7 and MariaDB 10.1.25
Hope someone can help me out on this one.
I added the inno_db_buffer_size to my.cnf as suggested, but whe
Hi, I adjusted the value and restarted the service, but when I run:
https://github.com/major/MySQLTuner-perl
It gives me the following output:
Hi, I adjusted the value and restarted the service, but when i run:
https://github.com/major/MySQLTuner-perl
It gives me the following output:
Set thread_cache_size to 4 as a starting value
Performance should be activated for better diagnostics
Consider installing Sys schema from https://github.com/mysql/mysql-sys
Variables to adjust:
query_cache_size (=0)
query_cache_type (=0)
query_cache_limit (> 1M, or use smaller result sets)
join_buffer_size (> 256.0K, or always use indexes with joins)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
thread_cache_size (start at 4)
performance_schema = ON enable PFS
innodb_buffer_pool_size (>= 139M) if possible.
innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
innodb_buffer_pool_instances (=1)
It seems to me that even though I adjusted the value, it's not reflected.
How can I check this?
It is okay that you do not see the innodb_buffer_pool_size. Most of MySQL parameters are not defined in /etc/my.cnf and database server uses the default ones. For innodb_buffer_pool_size it is 128M.
To set this value differ just define it in [mysqld] of /etc/my.cnf. For example innodb_buffer_pool_size = 512M
I would like to read an external file into MariaDB using the CONNECT engine. However, when trying to read from the file, I get an error message:
MariaDB [test]> create table test ( name varchar(100), team varchar(100) ) engine=CONNECT table_type=CSV file_name='/tmp/data.csv' header=1 sep_char=',' quoted=0;
Query OK, 0 rows affected (0.24 sec)
MariaDB [test]> select * from test;
ERROR 1296 (HY000): Got error 174 'Open() error 13 on /tmp/data.csv: Permission denied' from CONNECT
Checking the filesystem permissions gives me:
divingt#grisu ~ $ ls -l /tmp/data.csv
-rw-rw-rw- 1 divingt divingt 1658 Dec 31 13:59 /tmp/data.csv
So everybody should be able to read and write from the file.
Also in MYSQL the permissions allow for everything:
MariaDB [test]> SHOW GRANTS;
+------------------------------------------------------------------------------------------------+
| Grants for root#localhost |
+------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'#'localhost' IDENTIFIED VIA unix_socket WITH GRANT OPTION |
| GRANT PROXY ON ''#'%' TO 'root'#'localhost' WITH GRANT OPTION |
+------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
I run a Linux Mint system.
Thanks a lot for any help.
It turns out that the reason was that apparmor prevented mysqld from reading from reading the file. Disabling it (or changing the permissions) solved the problem.
I am using MariaDB 10.1 64x and experiencing error with FederatedX engine.
First, I create an server:
CREATE SERVER AAA_fed
Foreign data Wrapper mysql_1
OPTIONS (
User 'user1',
password 'password',
host 'x.x.x.x',
Port 3306,
database 'AAA'
);
and then create federated table using connection to the server.
CREATE TABLE table1
ENGINE = FEDERATED
CONNECTION='AAA_fed';
The table is created successfully, but when selecting data from it, it response an error:
Error Code: 1296. Got error 10000 'Error on remote system: 0: ' from
FEDERATED
Does anyone know the solution to this? I keep searching but cannot find the answer. Thank you.
WRAPPER should be a recognized connection protocol.
Example:
MariaDB [(none)]> SELECT VERSION();
+--------------------------+
| VERSION() |
+--------------------------+
| 10.1.14-MariaDB-1~xenial | -- 64 bit
+--------------------------+
1 row in set (0.00 sec)
MariaDB [(none)]> DROP DATABASE IF EXISTS `BBB`;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> DROP DATABASE IF EXISTS `AAA`;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> CREATE DATABASE IF NOT EXISTS `AAA`;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> CREATE DATABASE IF NOT EXISTS `BBB`;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> CREATE TABLE IF NOT EXISTS `AAA`.`table1` (
-> `id` int(20) NOT NULL,
-> `name` varchar(64) NOT NULL default ''
-> ) ENGINE='InnoDB';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> DROP SERVER IF EXISTS `AAA_fed`;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> CREATE SERVER IF NOT EXISTS `AAA_fed`
-> FOREIGN DATA WRAPPER `mysql_1` -- <-- Unsupported
-> OPTIONS (
-> HOST 'x.x.x.x',
-> DATABASE 'AAA',
-> USER 'user1',
-> PASSWORD 'password',
-> PORT 3306,
-> SOCKET '/path/to/mysqld.sock',
-> OWNER 'user1'
-> );
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> CREATE TABLE IF NOT EXISTS `BBB`.`table1`
-> ENGINE=FEDERATED CONNECTION='AAA_fed';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> SELECT `id`, `name` FROM `BBB`.`table1`;
ERROR 1296 (HY000): Got error 10000 'Error on remote system: 0: ' from FEDERATED
MariaDB [(none)]> DROP TABLE IF EXISTS `BBB`.`table1`;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> DROP SERVER IF EXISTS `AAA_fed`;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> CREATE SERVER IF NOT EXISTS `AAA_fed`
-> FOREIGN DATA WRAPPER `mysql` -- <-- Supported
-> OPTIONS (
-> HOST 'x.x.x.x',
-> DATABASE 'AAA',
-> USER 'user1',
-> PASSWORD 'password',
-> PORT 3306,
-> SOCKET '/path/to/mysqld.sock',
-> OWNER 'user1'
-> );
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> CREATE TABLE IF NOT EXISTS `BBB`.`table1`
-> ENGINE=FEDERATED CONNECTION='AAA_fed';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> SELECT `id`, `name` FROM `BBB`.`table1`;
Empty set (0.00 sec)
There is also one reason for this error. Which occurs when you created a federated table, that pointing to a table in the same server.
CDR was working before 19 march. Unfortunately i dont remember what kind of changes i made to configuration, but this exactly not changes to CDR config.
elastix 2.4.0
asterisk 11.7.0
mysql 5.0.95
elastix*CLI> cdr show status
Call Detail Record (CDR) settings
----------------------------------
Logging: Disabled
Mode: Simple
/etc/asterisk/cdr.conf
[general]
enable=yes
unanswered = yes
/etc/asterisk/cdr_mysql.conf
[global]
hostname = localhost
dbname=asteriskcdrdb
password = *MYPASSWROD*
user = asteriskcdruser
userfield=1
;port=3306
;sock=/tmp/mysql.sock
loguniqueid=yes
mysql> SHOW GRANTS FOR 'asteriskcdruser'#'localhost';
+-----------------------------------------------------------------------------------------------+
| Grants for asteriskcdruser#localhost |
+-----------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'asteriskcdruser'#'localhost' IDENTIFIED BY PASSWORD 'HASHHERE' |
| GRANT ALL PRIVILEGES ON `asteriskcdrdb`.* TO 'asteriskcdruser'#'localhost' |
+-----------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
Try do
asterisk -rx " module reload"
For mysql info see
asterisk -rx "cdr mysql status"