I have a production 64-bit MySQL DB server (version 5.1.69 - Source distribution) with 8 cores and 8 GB RAM, and I want it to fully utilize all cores and all available memory. I use InnoDB and I read that I should set the following in my.cnf configuration file:
innodb_read_io_threads = 64
innodb_write_io_threads = 64
From some reason, both variables don't exist. When I add them to the configuration file, MySQL fails to load. Moreover, the following query returns zero results:
show global variables like '%innodb_read_%';
Any suggestions? Thanks.
The InnoDB Plugin has been included in MySQL since version 5.1.38, but it has to be installed.
MySQL 5.5/5.6 has the new InnoDB Plugin installed by default. You could just upgrade to 5.5/5.6
If you really want to stay with MySQL 5.1.69, you can go to the MySQL Documentation on how to do the install of the InnoDB Plugin : http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-plugin-installation-dynamic-posix.html
I wrote about this in the DBA StackExchange back in May 2012 : https://dba.stackexchange.com/questions/18203/mysql-installing-innodb-plugin/18240#18240
Related
I'm attempting to configure failed login attempts with MariaDB 10.3. Using the following query (from mysql docs, hoping mariadb would be very similar):
ALTER USER 'mariadb_user'#'localhost' FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME UNBOUNDED;
This returns:
You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use
near 'FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME UNBOUNDED' at line 2
Does MariaDB actually support FAILED_LOGIN_ATTEMPTS? I didn't find anything useful when searching the documentation for relevant keywords.
This feature isn't supported by MariaDB.
As an alternative, you can use the global system variable max_password_errors which was introduced in MariaDB 10.4.
Note: max_password_errors will be ignored for localhost connections (:1, 127.0.0.1)
I had to redo my server (Debian 9) in Proxmox. I updated a package (libc6) and I broke the dependencies (I didn't snapshot it...). One of the affected daemons was MySQL / MariaDB, I could not make a backup from PhpMyAdmin because the daemon does not work and I could not connect to the database.
Now I have installed Debian 10, but I am having problems recovering the database from the other machine.
mysqldump: Couldn't execute 'show create table `xxx.yyy`': Table 'yyy' doesn't exist in engine (1932)
The following errors are prompted when I tried the following solutions:
root#debian:~# mysqldump -u root -p --all-databases > all_databases.sql
Enter password:
mysqldump: Got error: 1932: "Table 'mysql.gtid_slave_pos' doesn't exist in engine" when using LOCK TABLES
root#debian:~# mysqldump --skip-lock-tables -u root -p --all-databases > all_databases.sql
Enter password:
mysqldump: Couldn't execute 'show create table `gtid_slave_pos`': Table 'mysql.gtid_slave_pos' doesn't exist in engine (1932)
Source: https://support.plesk.com/hc/en-us/articles/213931725-Dump-of-the-MySQL-database-hosted-on-the-Plesk-server-fails-mysqldump-table-doesn-t-exist-when-using-LOCK-TABLES
root#debian:~# mysqlfrm --server=xxx:yyy#localhost:3306 test.frm --port=3310
WARNING: Using a password on the command line interface can be insecure.
# Source on localhost: ...
Usage: mysqlfrm --server=[user[:<pass>]#host[:<port>][:<socket>]|<login-path>[:<port>][:<socket>]] [path\tbl1.frm|db:tbl.frm]
mysqlfrm: error: Can't connect to MySQL server on 'localhost:3306' (111 Connection refused)
Source: https://dba.stackexchange.com/a/127813
MariaDB [(none)]> ALTER TABLE mysql.gtid_slave_pos DISCARD TABLESPACE;
ERROR 1932 (42S02): Table 'mysql.gtid_slave_pos' doesn't exist in engine
Source: Restore MySQL database using only .frm and .ibd files
Is there any option left?
EDIT:
I'll answer some questions danblack asked me.
How did I get into this state?
I don't exactly know it but I think that I broke MySQL after I tried to restart several times mysqld/mariadb service while I tried several solutions downgrading libc6 or trying to make mariadb to run again.
What was the MySQL/MariaDB version in Debian 9?
mariadb Ver 15.1 Distrib 10.1.44-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
What is the version in Debian 10?
mariadb Ver 15.1 Distrib 10.3.22-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
Did I copy the entire datadir from one to another?
No, I didn't try that... But I didn't find anything useful on stackoverflow sites nor google.
Did I run mysql_upgrade?
No, I didn't try that maybe by updating mariadb in Debian 9 could be a possible solution. But reviewing packages for Debian 9, I didn't found the mariadb 10.3 version for Debian 9 (the one that clib6 2.30-10 requires, I was on 2.14).
Can you take a mysqldump of other databases in the server (ie. not the mysql named one)?
Yes, I did backups for some databases but I couldn't backup all of them (only 3 or 4 from 10).
You have at least 2 options:
Option #1: Fix it in-place.
Create a snapshot and/or backup of the server before trying to fix anything.
Remove mariadb.
Install mariadb...which should fix any software issues preventing it from starting up.
Once it is working, create a backup of your databases using mysqldump.
Option #2: Create a new server.
Spin up another virtual machine just like it (install the same OS and MariaDB version).
Stop the new mariadb service and copy the database files from the old server to the new. The default location on Ubuntu is /var/lib/mysql/
Once you overwrite the files, start the mariadb service and jump into the mysql prompt to verify that the databases show up. (e.g. show databases;)
Once it is working, create a backup of your databases using mysqldump.
This is how I install MariaDB onto a server and setup automated backups: https://hammondslegacy.com/forum/viewtopic.php?f=40&t=266
The syntax is
`dbname`.`tablename`
not
`dbname.tablename`
Unfortunately, I will not be able to create a good repro for this issue without sharing confidential creds to the database I am having issues with. Hopefully I have enough information below to flag any obvious problems that ODBC experts will understand.
Background
I am running a MacBook Pro with the following specs:
Model Name: MacBook Pro
Model Identifier: MacBookPro15,1
Processor Name: 6-Core Intel Core i7
Processor Speed: 2.6 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 9 MB
Hyper-Threading Technology: Enabled
Memory: 32 GB
Boot ROM Version: 1037.0.78.0.0 (iBridge: 17.16.10572.0.0,0)
My ODBC connection is set using FreeTDS as specified here.
The relevant portion of freetds.conf is as follows:
# The POC SQL Server
[POC]
host = 172.22.238.154
port = 1433
tds version = 7.3
My odbcinst.ini file is as follows:
[FreeTDS]
Description=FreeTDS Driver for Linux & SQL Server
Driver=/usr/local/lib/libtdsodbc.so
Setup=/usr/local/lib/libtdsodbc.so
UsageCount=1
My odbc.ini file is specified as follows:
[POC]
Description = Connecton to Partners for our children SQL Server
Driver = FreeTDS
Servername = POC
I am trying to make a connection to a SQL Server 2012 database (via VPN) using the following connection information in R:
con <- DBI::dbConnect(odbc::odbc()
,dsn = "POC"
,uid = Sys.getenv("MSSQL_UN")
,database = "CA_ODS"
,pwd = Sys.getenv("MSSQL_PW"))
This generates the following connection object:
> con
<OdbcConnection> POC2
Database: CA_ODS
Microsoft SQL Server Version: 11.00.7001
In general, this connection works as expected. I can query the database using DBI::dbGetQuery(con, "select * from MyTable"), dplyr::tbl(con, MyTable), etc. without issue.
Problem
RStudio, however, is only displaying every other letter of the database objects, and truncating the object names after the first several letters. The following screenshot should illustrate the issue well:
The database I am trying to connect to is called CA_ODS. However, the RStudio object browser is only displaying every other letter of the database name (i.e. the DB is listed as C_D).
This does not appear to be limited to RStudio per se either. While the results of the actual database queries work fine as described above, the returned names from the INFORMATION_SCHEMA appear to match the information in the object browser. Below, when run directly from SQL Server Management Studio, the returned TABLE_CATALOG is CA_ODS, TABLE_SCHEMA is ndacan, etc. When run via the DB connection, however, I get the following.
> DBI::dbGetQuery(con, "SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_SCHEMA='ndacan'")
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE
1 C_D naa f21v BASE TABLE
Question
Any suggestions as to how I can respecify my ODBC connection in R or in my FreeTDS configs to get the full name of database objects returned?
As noted in #r2evans comments, this appears to be an issue with odbc, running in R 3.6.0, on a Mac.
In general, it appears that this can be fixed by reinstalling odbc from source install.packages("odbc", type = 'source').
As also noted in the comments, I had recently upgraded my Mac to Catalina. Prior to installing odbc from source I needed to first reinstall XCode using xcode-select --install from my terminal.
As can be seen in the screen capture below, I am now getting the full object names displayed from the odbc connection.
Is it possible to upgrade from 10.1.x to 10.3.x directly in one step? or I have to upgrade first to 10.2. x then to 10.3.x.
Please it is so important question regarding upgrading our production MariaDB servers and I couldn't find any answer or notes regarding upgrade from 10.1 series to 10.3 series.
So i have to do it as follow:
10.1.32 --> 10.2.16
10.2.16 --> 10.3.7
or
once 10.1.32 --> 10.3.7
In general, for any upgrade for a critical production environment:
The best approach is to use or create a test environment that is as close as possible to your production environment and test the upgrade there.
Make backups and prepare a rollback so you are ready to undo your changes
For MariaDB specifically: to quote from other related questions on their support pages:
The main concern with skipping versions is that, while upgrading one major version is usually well-tested, skipping versions is not, so you
may bump into an incompatibility
Even if you find anecdotal indications that it worked for others, a database engine like MariaDB has possible complexities with different storage engines and the like that might make it more tricky in certain setups than in others.
1 : Shutdown or Quit your XAMPP server from Xampp control panel.
2 : Download the ZIP version of MariaDB
3 : Rename the xampp/mysql folder to mysql_old.
4 : Unzip or Extract the contents of the MariaDB ZIP file into your XAMPP
folder.
5 : Rename the MariaDB folder, called something like mariadb-5.5.37-win32, to
mysql.
6 : Rename xampp/mysql/data to data_old.
7 : Copy the xampp/mysql_old/data folder to xampp/mysql/.
8 : Copy the xampp/mysql_old/backup folder to xampp/mysql/.
9 : Copy the xampp/mysql_old/scripts folder to xampp/mysql/.
10: Copy mysql_uninstallservice.bat and mysql_installservice.bat from
xampp/mysql_old/ into xampp/mysql/.
11 : Copy xampp/mysql_old/bin/my.ini into xampp/mysql/bin.
12 : Edit xampp/mysql/bin/my.ini using a text editor like Notepad. Find skip-federated and add a # in front (to the left) of it to comment out the line if it exists. Save and exit the editor.
13 : Start-up XAMPP.
Note If you can't get mysql to start from Xampp control panel.
Add this 'skip-grant-tables' statement anywhere in xampp/mysql/bin/my.ini
file
14 : Run xampp/mysql/bin/mysql_upgrade.exe.
15 : Shutdown and restart MariaDB (MySQL).
If still mysql is not started then follow below Note steps(!Important)
Note :mysql error log file: c:\xampp\mysql\bin\mysqld.exe: unknown variable 'innodb_additional_mem_pool_size=2M' like please remove or commented this statement in my.ini file in this path xampp/mysql/bin/my.ini file.
Help from this link.
This is making me kind of crazy: I did a mysqldump of a partitioned table on one server, moved the resulting SQL dump to another server, and attempted to run the insert. It fails, but I'm having difficulty figuring out why. Google and the MySQL forums and docs have not been much help.
The failing query looks like this (truncated for brevity and clarity, names changed to protect the innocent):
CREATE TABLE `my_precious_table` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`somedata` varchar(20) NOT NULL,
`aTimeStamp` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
PRIMARY KEY (`id`,`aTimeStamp`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 DATA DIRECTORY='/opt/data/data2/data_foo/' INDEX DIRECTORY='/opt/data/data2/idx_foo/'
/*!50100 PARTITION BY RANGE (year(aTimeStamp)) SUBPARTITION BY HASH ( TO_DAYS(aTimeStamp))
(PARTITION p0 VALUES LESS THAN (2007) (SUBPARTITION foo0 DATA DIRECTORY = '/opt/data/data2/data_foo' INDEX DIRECTORY = '/opt/data/data2/idx_foo' ENGINE = MyISAM),
PARTITION p1 VALUES LESS THAN (2008) (SUBPARTITION foo1 DATA DIRECTORY = '/opt/data/data2/data_foo' INDEX DIRECTORY = '/opt/data/data2/idx_foo' ENGINE = MyISAM),
PARTITION p2 VALUES LESS THAN (2009) (SUBPARTITION foo2 DATA DIRECTORY = '/opt/data/data2/data_foo' INDEX DIRECTORY = '/opt/data/data2/idx_foo' ENGINE = MyISAM),
PARTITION p3 VALUES LESS THAN MAXVALUE (SUBPARTITION foo3 DATA DIRECTORY = '/opt/data/data2/data_foo' INDEX DIRECTORY = '/opt/data/data2/idx_foo' ENGINE = MyISAM)) */;
The error is:
ERROR 1 (HY000): Can't create/write to file '/opt/data/data2/idx_foo/my_precious_table#P#p0#SP#foo0.MYI' (Errcode: 13)
"Can't create/write to file" looked like a permissions issue to me, but permissions on the targeted folders look thus:
drwxrwxrwx 2 mysql mysql 4096 Dec 1 16:24 data_foo
drwxrwxrwx 2 mysql mysql 4096 Dec 1 16:25 idx_foo
For kicks, I've tried chowning to root:root and myself. This did not fix the issue.
Source MySQL server is version 5.1.22-rc-log. Destination server is 5.1.29-rc-community. Both are running on recent CentOS installations.
Edit: A little more research shows that Errcode 13 is, in fact, a permissions error. But how can I get that on rwxrwxrwx?
Edit: Bill Karwin's excellent suggestion didn't pan out. I'm working as the root user, and have all privilege flags set.
Edit: Creating the table WITHOUT specifying data directories for the individual partitions works - but I need to put these partitions on a larger disk than the one on which this MySQL instance puts tables by default. And I can't just specify the DATA/INDEX DIRECTORY at the table level - that's not legit in the version of MySQL I'm using (5.1.29-rc-community).
Edit: Finally came across the answer, thanks to the MySQL mailing list and internal IT staff. See below.
On Ubuntu look into the apparmor settings for mysql
vi /etc/apparmor.d/usr.sbin.mysql
This should solve the permission issues. For a quick test you can even try
/etc/init.d/apparmor stop
But don't forget to restart the service.
This took me some time to figure out. And after reading "SELinux" it was clear that I have forgotten this new kind of protection on Ubuntu.
http://bugs.mysql.com/bug.php?id=19557
You will also receive an error message
of the MySQL user ID running the query
does not have "DATA FILE" privileges
that allows the user ID to write to
the file system.
In other words, it can be a permission problem with respect to SQL privileges, not operating system file permissions.
It turned out to be an SElinux issue - all my filesystem permissions were fine, but there was a higher-level policy set against MySQL accessing that disk partition.
Lesson: When you have a permissions issue but ownership and filesystem permissions are obviously correct, look to SElinux.