另一個MySQL DBA: 六月 2013

2013年6月29日星期六

這麼好笑分享...

MySQL錯誤＃20786得到的蛋糕！

http://www.youtube.com/watch?v=oAiVsbXVP6k

MySQL Bug #20786 gets cake !

http://www.youtube.com/watch?v=oAiVsbXVP6k

The laugh at the end is the best part.
http://bugs.mysql.com/bug.php?id=20786

2013年6月16日星期日

備份和恢復MySQL的腳本使用Percona的innobackup Xtrabackup

Original post: http://anothermysqldba.blogspot.com/2013/06/backup-and-recovery-script-for-mysql.html

所以Percona的廣泛使用的備份工具Xtrabackup，他們意識到，每個人都經常使用這個工具在某種類型的腳本。有一個頁面，談到：

由於我最近做了一個例子，如何使用備份在以前的帖子。我想我還不如寫一個腳本顯示了如何腳本在備份過程。再加上它已經多年，因為我寫在Python，所以我希望得到一點點的做法。

因此，引進的代碼是下面，但我已經在github上放置腳本。
這需要進行更多的測試，但隨時檢查代碼庫，更新和編輯。

一旦代碼被測試了，我可以更新的例子，但我想成為這個項目從一開始就開放。

因為它是在早期階段，我會建議使用 - showcommands = 1選項，所以你可以看到代碼計劃做什麼，也許嘗試這些命令。顯然，它不應該被用於在生產系統中的評價。

首先介紹：


# ./backup_restore.py --help
Usage: backup_restore.py --process=[fullbackup,incremental,prepare,restore] --help --version --showcommands=1

This program enables you to backup full and incremental backups then prepare
and restore them using Percona's Xtrabackup

Options:
--version show program's version number and exit
-h, --help show this help message and exit
--process=PROCESS What would you like to do --process=
[fullbackup,incremental,prepare,restore]
--debug=DEBUG TURN DEBUG ON 1 OR OFF 0 OR VERBOSE 3
--showcommands=SHOWCOMMANDS
Shows the commands instead of executing them except
for the restore section because we go through that
step by step
--backup_root_directory=BACKUP_ROOT_DIRECTORY
THE ROOT DIRECTORY OF ALL YOUR BACKUPS, You can set
DEFAULT at start of the script
--percona_xtrabackup_location=PERCONA_XTRABACKUP_LOCATION
THE LOCATION OF YOUR xtrabackup FILE, You can set
DEFAULT at start of the script
--datadir=DATADIR MYSQL DATA DIR LOCATION, You can set DEFAULT at start
of the script
--username=DB_USERNAME
MySQL Username, You can set DEFAULT at start of the
script
--password=DB_PASSWORD
MySQL Password, You can set DEFAULT at start of the
script
--default_file=DEFAULT_FILE
MySQL my.cnf file location, You can set DEFAULT at
start of the script
--options=PERCONA_OPTIONS
Additional Options for innobackupex

2013年6月14日星期五

max_binlog_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/06/maxbinlogcachesize.html

當你評估你的數據庫的性能和穩定性，它很可能你會開始檢討變量。

在看下面的變量是典型的第一反應.. 等待，什麼是錯的，我的盒子沒有那麼多內存或磁盤空間，以滿足下面列出的最大限制......


MariaDB [(none)]> select @@max_write_lock_count, @@max_binlog_cache_size, @@max_seeks_for_key, @@myisam_max_sort_file_size\G
*************************** 1. row ***************************
@@max_write_lock_count: 4294967295                     -- 4 GB
@@max_binlog_cache_size: 1844674407370954752          --1.6 EB
@@max_seeks_for_key: 429496729                         -- 4 GB
@@myisam_max_sort_file_size: 9223372036853727232        --8 EB

你並不孤單，在關注這些變量關於這些變量的已上市多年來的一些錯誤。下面是一些遺留的只是一小部分。

“ MySQL目前不能使用大於4GB的二進制日誌的位置。“
請記住，這些只是默認和MAX設置。你可以調整他們讓你感覺更舒服。


MariaDB [(none)]> SET GLOBAL max_binlog_cache_size = 4294967296;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SELECT @@max_binlog_cache_size;
+-------------------------+
| @@max_binlog_cache_size |
+-------------------------+
| 4294967296 | -- 4GB
+-------------------------+
1 row in set (0.00 sec)

為什麼你會要... 這是一個完全不同的話題。這只是允許的上限和交易取得分割為4GB反正。 “的最大建議值是4GB “，使您可以更新它，如果你選擇太。

閱讀更多關於選項在MySQL文檔：

http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_max_binlog_cache_size

2013年6月13日星期四

MariaDB的10.0.3 Alpha安裝在Fedora 17 x86_64的

Original post: http://anothermysqldba.blogspot.com/2013/06/mariadb-1003-alpha-install-on-fedora-17.html

，MariaDB的10.0.3阿爾法剛剛發布。
因此，對於那些你還記得我以前MariaDB的5.5安裝後，我決定看看它是如何工作10.0.3。

我喜歡的一些功能MariaDB的和Percona的版本的進入。即使你是一個大支持者，當MySQL的特點是可以在這些版本不移植到MySQL版本的數據庫管理員必須檢討自己的選擇，並做出選擇。

因此，安裝......

正如我之前所說，從以前的帖子，我有這個安裝。所以我只是先升級。


 [root@Fedora64 10]# rpm -qa | grep maria 
 mariadb-5.5.31-1.fc17.x86_64 
 mariadb-server-5.5.31-1.fc17.x86_64 
 mariadb-libs-5.5.31-1.fc17.x86_64 
 mariadb-bench-5.5.31-1.fc17.x86_64 
 mariadb-devel-5.5.31-1.fc17.x86_64

SO封裝在開始發生衝突。


 MariaDB-10.0.3-fedora17-x86_64-client.rpm 
 MariaDB-10.0.3-fedora17-x86_64-common.rpm 
 MariaDB-10.0.3-fedora17-x86_64-compat.rpm 
 MariaDB-10.0.3-fedora17-x86_64-connect-engine.rpm 
 MariaDB-10.0.3-fedora17-x86_64-devel.rpm 
 MariaDB-10.0.3-fedora17-x86_64-server.rpm 
 MariaDB-10.0.3-fedora17-x86_64-shared.rpm 
 MariaDB-10.0.3-fedora17-x86_64-test.rpm

[root@Fedora64 10]# rpm -Uhv *.rpm 
 warning: MariaDB-10.0.3-fedora17-x86_64-client.rpm: Header V3 DSA/SHA1 Signature, key ID 1bb943db: NOKEY 
 error: Failed dependencies: 
 libodbc.so.2()(64bit) is needed by MariaDB-connect-engine-10.0.3-1.x86_64 
 MySQL-devel conflicts with (installed) mariadb-devel-5.5.31-1.fc17.x86_64

MariaDB-server-10.0.3-1.x86_64 conflicts with file from package mariadb-server-5.5.31-1.fc17.x86_64
[root@Fedora64 10]#

所以這只是一個VirtualBox的實例,用於演示和評估，所以我只是刪除了所有我能不得不卸載。我希望升級工作，但仍然是阿爾法代碼。
即：


 [root@Fedora64 10]# rpm -e mariadb mariadb-server mariadb-bench 
 [root@Fedora64 10]# rpm -e mariadb-libs perl-DBD-MySQL percona-xtrabackup

所以，現在，過去被清除出...


 [root@Fedora64 10]# rpm -ihv *.rpm 
 Preparing...                ########################################### [100%] 
 1:MariaDB-common         ########################################### [ 11%] 
 2:MariaDB-server         ########################################### [ 22%] 
 3:MariaDB-cassandra-engin########################################### [ 33%] 
 4:MariaDB-client         ########################################### [ 44%] 
 5:MariaDB-devel          ########################################### [ 56%] 
 6:MariaDB-shared         ########################################### [ 67%] 
 7:MariaDB-test           ########################################### [ 78%] 
 8:MariaDB-compat         ########################################### [ 89%] 
 9:galera                 ########################################### [100%]

如果你還記得過去後，我得到了init.d腳本這個時候..


 [root@Fedora64 10]# /etc/init.d/mysql start 
 Starting MySQL..... SUCCESS! 
 [root@Fedora64 10]# mysql 
 Welcome to the MariaDB monitor.  Commands end with ; or \g. 
 Your MariaDB connection id is 2 
 Server version: 10.0.3-MariaDB MariaDB Server

如果他們是不可怕的表現，然後我不明白為什麼這些是不是在默認情況下：


 vi /etc/my.cnf 
 [mysqld]

userstat=1
# http://www.percona.com/doc/percona-server/5.5/diagnostics/user_stats.html?id=percona-server:features:userstatv2
# https://kb.askmonty.org/en/user-statistics/

feedback=ON 
 # https://kb.askmonty.org/en/user-feedback-plugin/ 
 MariaDB [(none)]> show variables like '%feedback%'; 
 +--------------------------+------------------------------------------+ 
 | Variable_name            | Value                                    | 
 +--------------------------+------------------------------------------+ 
 | feedback_send_retry_wait | 60                                       | 
 | feedback_send_timeout    | 60                                       | 
 ... 
 | feedback_url             | https://mariadb.org/feedback_plugin/post | 
 | feedback_user_info       |                                          | 
 +--------------------------+------------------------------------------+

MariaDB [(none)]> show variables like '%userstat%'; 
 +---------------+-------+ 
 | Variable_name | Value | 
 +---------------+-------+ 
 | userstat      | ON    | 
 +---------------+-------+

問題我安裝後發現30秒，...：


 MariaDB [(none)]> show variables; 
 ERROR 1946 (HY000): Failed to load replication slave GTID position from table mysql.gtid_slave_pos

這是迄今為止... 我安裝了它，現在可以查看...

更新：
我已提交了一個錯誤。 MariaDB的團隊得到了右後衛給我，指出我無法運行mysql_upgrade並重新啟動。固定上面列出的錯誤。仍存變數感覺像它應該顯示它的一切，但我的一部分，這是一個有效的修復和錯誤。謝謝MariaDB的團隊。

要了解更多信息：

2013年6月12日星期三

MySQL < 5.5 replication to MySQL 5.6

Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-55-replication-to-mysql-56.html

經過幾個小時的無奈..... 我會簡單地把它作為不升級到MySQL 5.6中，如果你正在運行任何版本的MySQL 5.5。

你必須升級到MySQL 5.5第一，保持你的理智和數據機智。

在MySQL 5.6中的密碼更改，並提供大量的博客文章和信息，我支持他們。我什至更新的MySQL 5.6密碼盒子是運行得很好。問題是複製。我不得不從一個MySQL版本複製小於MySQL 5.5中，它根本不會運行。我禁用secure_auth可以連接，但仍然沒有運氣與複製。

雖然我支持複製的升級路徑，走的時候，並堅持先與MySQL 5.5。

我結束了降級到MySQL 5.5，現在一切都運行得很好。如果你有你的MySQL版本降級，我必須遵循相同的步驟，我在我的瑪麗亞diaster後箱體背部。

2013年6月10日星期一

Percona的Xtrabackup / innobackupex備份和恢復進程

Original post: http://anothermysqldba.blogspot.com/2013/06/percona-xtrabackupinnobackupex-backup.html

這是一個非常簡單的例子，如何使用Percona的Xtrabackup / innobackupex

MariaDB的只是在它的世界數據庫作為一個例子數據。
這一切都可以編寫腳本，但現在它是用於演示目的。

創建一個完整的備份：

MariaDB [(none)]> create database Start_Of_Demo; -- Just here for the demo
Query OK, 1 row affected (0.00 sec)


[root@Fedora64 src]# innobackupex --no-lock --parallel=4 --user=root --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ --no-timestamp /usr/local/src/fullbackup/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/fullbackup'
130609 15:41:39 innobackupex: Connection to database server closed
130609 15:41:39 innobackupex: completed OK!

[root@Fedora64 src]# ls -al fullbackup/
total 18472
drwxr-xr-x. 6 root root 4096 Jun 9 15:41 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:41 backup-my.cnf
-rw-r-----. 1 root root 18874368 Jun 9 15:41 ibdata1
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 world
-rw-r--r--. 1 root root 13 Jun 9 15:41 xtrabackup_binary
-rw-r-----. 1 root root 89 Jun 9 15:41 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:41 xtrabackup_logfile

創建一個增量備份：

MariaDB [(none)]> create database incremental_1; -- Just here for the demo

Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]#innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental'
130609 15:47:20 innobackupex: Connection to database server closed
130609 15:47:20 innobackupex: completed OK!

[root@Fedora64 src]# ls -al incremental
total 64
drwxr-xr-x. 7 root root 4096 Jun 9 15:47 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:47 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:47 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:47 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 world
-rw-r--r--. 1 root root 13 Jun 9 15:47 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:47 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:47 xtrabackup_logfile

創建另一個增量備份：

MariaDB [(none)]> create database incremental_2;-- Just here for the demo

Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]# innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental_2/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental_2'
130609 15:49:49 innobackupex: Connection to database server closed
130609 15:49:49 innobackupex: completed OK!
[root@Fedora64 src]# ls -al incremental_2
total 68
drwxr-xr-x. 8 root root 4096 Jun 9 15:49 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:49 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:49 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:49 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_2
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 world
-rw-r--r--. 1 root root 13 Jun 9 15:49 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:49 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:49 xtrabackup_logfile

現在你必須牢記這一點。

數據庫中當然是關閉。

如果你正在做一個還原，它可能是反正它墜毀

確保服務器已關閉，然後清除我們的數據目錄。

[root@Fedora64 src]# ps -ef | grep mysql

root 4538 1940 0 15:54 pts/2 00:00:00 grep --color=auto mysql

[root@Fedora64 src]# ls -al /var/lib/mysql/

total 28724

drwxr-xr-x. 8 mysql mysql 4096 Jun 9 15:53 .

drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..

-rw-rw----. 1 mysql mysql 16384 Jun 9 15:53 aria_log.00000001

-rw-rw----. 1 mysql mysql 52 Jun 9 15:53 aria_log_control

-rw-r--r--. 1 mysql mysql 18874368 Jun 9 15:53 ibdata1

-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:53 ib_logfile0

-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:17 ib_logfile1

drwx------. 2 mysql mysql 4096 Jun 9 15:43 incremental_1

drwx------. 2 mysql mysql 4096 Jun 9 15:48 incremental_2

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 mysql

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 performance_schema

drwx------. 2 mysql mysql 4096 Jun 9 15:40 Start_Of_Demo

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 world

[root@Fedora64 src]# rm -Rf /var/lib/mysql/*

現在你必須牢記這一點。當您創建備份和增量備份，你必須先恢復完全備份，然後套用所有增量備份。所以，不要認為你可以做一個完整備份後剛剛恢復的最後一個增量。永遠記住，你能承受多少增量備份另一個完全備份之前需要。

要恢復完全備份：

innobackupex --copy-back /usr/local/src/fullbackup/

innobackupex: Starting to copy InnoDB log files

innobackupex: in '/usr/local/src/fullbackup'

innobackupex: back to original InnoDB log directory '/var/lib/mysql'

innobackupex: Finished copying back files.

130609 15:54:57 innobackupex: completed OK!

[root@Fedora64 src]# ls -al /var/lib/mysql/

total 18456

drwxr-xr-x. 6 mysql mysql 4096 Jun 9 15:54 .

drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..

-rw-r--r--. 1 root root 18874368 Jun 9 15:54 ibdata1

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 mysql

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 performance_schema

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 Start_Of_Demo

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 world

[root@Fedora64 mysql]# mysql

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 1

Server version: 5.5.31-MariaDB MariaDB Server

這不完整備份，但在那之後，我提出了增量備份。因此，將要關閉和清理出來的數據目錄。為什麼呢？你必須，申請增量備份的完整，然後將其還原。如下面的示例所示：

innobackupex --apply-log --redo-only /usr/local/src/fullbackup/

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

130609 15:57:59 InnoDB: Starting shutdown...

130609 15:58:00 InnoDB: Shutdown completed; log sequence number 1597964

130609 15:58:00 innobackupex: completed OK!

現在，讓我們把第一個增量目錄。你可以看到在下面的例子中，現在應用在fullbackup目錄的incremental_1目錄。這是沒有的情況下。

innobackupex --apply-log --redo-only /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental/

130609 15:58:42 innobackupex: completed OK!

[根@ Fedora64 SRC]＃LS-AL fullbackup /

共20520

drwxr-XR-X。 7根4096 6月9日15:58。

drwxr-XR-X。 6根4096 6月9日15時49分..

RW-R - R - 。 1根260 6月9日15:41備份的my.cnf

RW-R -----。 1根6月9日15:58 ibdata1的18874368

drwxr-XR-X。 2根4096年6月9 15:58 incremental_1

drwxr-XR-X。 2根4096年6月9 15:41 mysql的

drwxr-XR-X。 2根4096年6月9 15:41 PERFORMANCE_SCHEMA的

drwxr-XR-X。 2根4096年6月9 15:41 Start_Of_Demo

drwxr-XR-X。 2根4096年6月9 15:41 世界

RW-R - R - 。 1根13 6月9日15:41 xtrabackup_binary

RW-R -----。 1根89 6月9日15:58 xtrabackup_checkpoints

RW-R -----。 1根6月9日15:58 xtrabackup_logfile 2097152

現在我們將第二個增量目錄。你可以看到在下面的例子中，現在應用在fullbackup目錄的incremental_2目錄。這是沒有的情況下。

innobackupex --apply-log /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental_2/

innobackupex：複製'/ usr/local/src/incremental_2/Start_Of_Demo/db.opt的'到'/ USR /本地/ SRC / fullbackup / Start_Of_Demo / db.opt'

130609 16:00:09 innobackupex：完成OK！

[根@ Fedora64 SRC]＃LS-AL fullbackup /

共20524

drwxr-XR-X。 8根4096 6月9日16:00。

drwxr-XR-X。 6根4096 6月9日15時49分..

RW-R - R - 。 1根260 6月9日15:41備份的my.cnf

RW-R -----。 1根18874368 6月9日16:00的ibdata1

drwxr-XR-X。 2根4096年6月9 15:58 incremental_1

drwxr-XR-X。 2根4096年6月9 16:00 incremental_2

drwxr-XR-X。 2根4096年6月9 15:41 mysql的

drwxr-XR-X。 2根4096年6月9 15:41 PERFORMANCE_SCHEMA的

drwxr-XR-X。 2根4096年6月9 15:41 Start_Of_Demo

drwxr-XR-X。 2根4096年6月9 15:41 世界

RW-R - R - 。 1根13 6月9日15:41 xtrabackup_binary

RW-R -----。 1根89 6月9日16:00 xtrabackup_checkpoints

RW-R -----。 1根6月9日15:58 xtrabackup_logfile 2097152

現在我們將完全備份目錄。你可以看到在下面的例子中，現在應用在fullbackup目錄的incremental_2目錄。這是沒有的情況下。

[root@Fedora64 src]# rm -Rf /var/lib/mysql/*

[根@ Fedora64 SRC]＃innobackupex - 複製回的/ usr /本地/ SRC / fullbackup /

[根@ Fedora64 SRC]＃喬敦-R的mysql：mysql的的/ var / lib / mysql的中

現在一切都恢復和可供選擇：

[root@Fedora64 mysql]# mysql

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 1

Server version: 5.5.31-MariaDB MariaDB Server

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;

+--------------------+

| Database |

+--------------------+

| information_schema |

| Start_Of_Demo |

| incremental_1 |

| incremental_2 |

| mysql |

| performance_schema |

| world |

+--------------------+

可供參考的鏈接。

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html

2013年6月9日星期日

百勝安裝MariaDB的/ MySQL的災難，但固定的

Original post: http://anothermysqldba.blogspot.com/2013/06/yum-install-mariadbmysql-disaster-but.html

因此，這應該是一個簡單的MariaDB的/ MySQL的安裝。我不認為這是一個瑪利亞問題，但只是一個整體的錯誤。這裡是發生了什麼事，我怎麼固定它。

yum安裝MariaDB的服務器
然後我說休息，有什麼你看到下面。

[root@Fedora64 log]# rpm -qa | grep maria 
 mariadb-5.5.31-1.fc17.x86_64 
 mariadb-server-5.5.31-1.fc17.x86_64 
 mariadb-libs-5.5.31-1.fc17.x86_64 
 mariadb-devel-5.5.31-1.fc17.x86_64

我認為這是奇怪的是，我沒有得到一個/ etc / init.d / mysql下的文件，但我用它去，我想看看發生了什麼事。

[root@Fedora64 log]# mysqld_safe 
 130608 19:54:36 mysqld_safe Logging to '/var/log/mysqld.log'. 
 130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 
 130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 
 
 130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 
 130608 19:54:37 InnoDB: The InnoDB memory heap is disabled 
 130608 19:54:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
 130608 19:54:37 InnoDB: Compressed tables use zlib 1.2.5 
 130608 19:54:37 InnoDB: Using Linux native AIO 
 130608 19:54:37 InnoDB: Initializing buffer pool, size = 128.0M 
 130608 19:54:37 InnoDB: Completed initialization of buffer pool 
 130608 19:54:37 InnoDB: highest supported file format is Barracuda. 
 130608 19:54:38  InnoDB: Waiting for the background threads to start 
 130608 19:54:39 Percona XtraDB (http://www.percona.com) 5.5.31-MariaDB-30.2 started; log sequence number 1597945 
 130608 19:54:39 [Note] Plugin 'FEEDBACK' is disabled. 
 130608 19:54:39 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 
 130608 19:54:39 [Note] Server socket created on IP: '0.0.0.0'. 
 130608 19:54:39 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist 
 130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

哇... 第一次運行和失敗是不是一個好兆頭。這是一個全新的安裝mysql目錄應該已經安裝。於是我開始與 - 跳過批表，這樣我就可以進入禁區，環顧四周。

[root@Fedora64 mysql]# ls -la 
 total 28700 
 drwxr-xr-x.  2 mysql mysql     4096 Jun  8 19:58 . 
 drwxr-xr-x. 43 root  root      4096 Jun  8 19:41 .. 
 -rw-rw----.  1 mysql mysql    16384 Jun  8 19:50 aria_log.00000001 
 -rw-rw----.  1 mysql mysql       52 Jun  8 19:50 aria_log_control 
 -rw-rw----.  1 mysql mysql 18874368 Jun  8 19:50 ibdata1 
 -rw-rw----.  1 mysql mysql  5242880 Jun  8 19:58 ib_logfile0 
 -rw-rw----.  1 mysql mysql  5242880 Jun  8 19:45 ib_logfile1 
 [root@Fedora64 mysql]# 
 
 [root@Fedora64 mysql]# mysqld_safe --skip-grant-tables 
 130608 20:02:45 mysqld_safe Logging to '/var/log/mysqld.log'. 
 130608 20:02:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

確定開始... 不運行，但仍然是一個主要的問題仍然沒有mysql表！

[root@Fedora64 /]# mysql_upgrade 
 Phase 1/3: Fixing table and database names 
 Phase 2/3: Checking and upgrading tables 
 Processing databases 
 information_schema 
 Phase 3/3: Running 'mysql_fix_privilege_tables'... 
 ERROR 1049 (42000): Unknown database 'mysql' 
 FATAL ERROR: Upgrade failed

這仍然可以被固定....

[root@Fedora64 /]# mysql 
 Welcome to the MariaDB monitor.  Commands end with ; or \g. 
 Your MariaDB connection id is 10 
 Server version: 5.5.31-MariaDB MariaDB Server 
 
 Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. 
 
 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 
 
 MariaDB [(none)]> show databases; 
 +--------------------+ 
 | Database           | 
 +--------------------+ 
 | information_schema | 
 +--------------------+ 
 1 row in set (0.01 sec) 
 
 MariaDB [(none)]> create database mysql ; 
 Query OK, 1 row affected (0.13 sec) 
 
 MariaDB [(none)]> exit 
 Bye

OK，現在它有一個mysql表，我應該能夠把它升級

[root@Fedora64 /]# mysql_upgrade 
 Phase 1/3: Fixing table and database names 
 Phase 2/3: Checking and upgrading tables 
 Processing databases 
 information_schema 
 mysql 
 Phase 3/3: Running 'mysql_fix_privilege_tables'... 
 OK 
 [root@Fedora64 /]#

確定，所以我停止mysqld和啟動它而沒有 - 跳補助畢竟剛安裝了它，我還沒有設置密碼。

[root@Fedora64 mysql]# mysqld_safe 
 [root@Fedora64 /]# mysql 
 ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

好了，所以讓我再試一次......

[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables 
 
 MariaDB [mysql]> show tables; 
 +---------------------------+ 
 | Tables_in_mysql           | 
 +---------------------------+ 
 | columns_priv              | 
 | db                        | 
 | event                     | 
 | func                      | 
 | general_log               | 
 | help_category             | 
 | help_keyword              | 
 | help_relation             | 
 | help_topic                | 
 | host                      | 
 | ndb_binlog_index          | 
 | plugin                    | 
 | proc                      | 
 | procs_priv                | 
 | proxies_priv              | 
 | servers                   | 
 | slow_log                  | 
 | tables_priv               | 
 | time_zone                 | 
 | time_zone_leap_second     | 
 | time_zone_name            | 
 | time_zone_transition      | 
 | time_zone_transition_type | 
 | user                      | 
 +---------------------------+ 
 24 rows in set (0.01 sec) 
 
 MariaDB [mysql]> select * from user; 
 Empty set (0.00 sec) 
 
 MariaDB [(none)]>  create user root ;

我不能使用下面的命令，因為啟用 - 跳批表。
建立用戶根確定“;

所以現在我有一個root用戶只能通過名字，因為它具有零權限。

MariaDB [(none)]> show databases; 
 +--------------------+ 
 | Database           | 
 +--------------------+ 
 | information_schema | 
 +--------------------+ 
 1 row in set (0.00 sec)

所以我要再次入禁區 - 啟用跳過批表，更新根帳戶

UPDATE user 
 SET Select_priv = 'Y', 
 Insert_priv='Y', 
 Update_priv='Y', 
 Delete_priv='Y', 
 Create_priv='Y', 
 Drop_priv='Y', 
 Reload_priv='Y', 
 Shutdown_priv='Y', 
 Process_priv='Y', 
 File_priv='Y', 
 Grant_priv='Y', 
 References_priv='Y', 
 Index_priv='Y', 
 Alter_priv='Y', 
 Show_db_priv='Y', 
 Super_priv='Y', 
 Create_tmp_table_priv='Y', 
 Lock_tables_priv='Y', 
 Execute_priv='Y', 
 Repl_slave_priv='Y', 
 Repl_client_priv='Y', 
 Create_view_priv='Y', 
 Show_view_priv='Y', 
 Create_routine_priv='Y', 
 Alter_routine_priv='Y', 
 Create_user_priv='Y', 
 Event_priv='Y', 
 Trigger_priv='Y', 
 Create_tablespace_priv='Y' 
 WHERE user = 'root';

現在不重新啟動 - 啟用跳過發放表，我作為root！

[root@Fedora64 /]# ps -ef | grep mysql 
 root      4522  1513  0 20:26 pts/0    00:00:00 /bin/sh /bin/mysqld_safe 

 mysql     4650  4522  0 20:27 pts/0    00:00:03 /usr/libexec/mysqld 
--basedir=/usr --datadir=/var/lib/mysql 
--plugin-dir=/usr/lib64/mysql/plugin --user=mysql 
--log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid 
--socket=/var/lib/mysql/mysql.sock 
 root      8348  3178  0 20:47 pts/1    00:00:00 grep --color=auto mysql 
 [root@Fedora64 /]# mysql 
 Welcome to the MariaDB monitor.  Commands end with ; or \g. 
 Your MariaDB connection id is 2 
 Server version: 5.5.31-MariaDB MariaDB Server 
 
 Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. 
 
 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 
 
 MariaDB [(none)]>

噢。這是一個例子，如何解決它，當事情出錯，但我還是想在/ etc / init.d / mysql下的文件

2013年6月8日星期六

透視表“或”否透視表

Original post: http://anothermysqldba.blogspot.com/2013/06/piviot-table-or-no-pivot-table.html

這個話題最近想出上forums.mysql.com網站。

表達的意見是很難擴展和維護，這將是值得重新設計架構，而不是透視表數據透視表。這是一個有效的意見與有效點。

我想在這裡添加主題幫助表達我的觀點，並為他人提供。

這一切都取決於正在收集關於是否應該使用數據透視表或數據。我在以前的帖子中給出的例子只是一個例子，他們是如何工作的。

如果你正在收集已知的用戶信息（第一個和最後一個名字，地址信息，電話），然後是一個數據透視表更複雜，你需要什麼。如果你只是有幾個數據點，以配合他們到外，核心信息，然後是另一個表是一個解決方案，並綁用一個簡單的連接。

數據透視表的概念是有效的，當它是動態量的每個實體所收集的數據。
您可能需要10個數據點100個用戶。您可能需要500未來100用戶的數據點。架構可以很容易處理？

在以前的帖子中給出的例子，我同意不要求一個數據透視表。但我只是用在論壇給我的概念來回答這個問題問。

理想的情況下，你可以使用這兩種模式中的解決方案。核心數據點，保持在列。動態數據保留在數據透視表中。

如果它是建立正確的可伸縮性非常大，億萬我存儲在數據透視表的數據證明了這一點對我來說很容易。這並不意味著它不會需要一些工作。你很可能會發現，創造了一些意見或匯總表，數據透視表看起來會更容易為他人收集數據。這引出了一個問題，那麼為什麼不以那種方式存儲的數據擺在首位？再次，這取決於您的數據和應用程序使用數據的動態性質。

內存和臨時表

\Original post: http://anothermysqldba.blogspot.com/2013/06/memory-and-temporary-tables.html

既然我已經收到了與博客要求，幫助答案forum.mysql.com問題，我會繼續在這裡發表一些擴展的例子。

我注意到了這一點： http://forums.mysql.com/read.php?10後，588192,588192＃MSG-588192 ，我首先想到的是用不同的方式來處理這種情況。

如果你需要處理臨時信息表，你可以去了解它在兩個方面。如果是每會話處理，那麼你應該創建一個臨時表：

CREATE TEMPORARY TABLE `temporary_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ;

這將導致NO。FRM文件將消失，關閉會話。

如果你需要它不再需要它要快，你可以使用一個MEMORY表。這將一直保留，直到重新啟動數據庫，刪除表，等..

CREATE TABLE `memory_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=MEMORY;

這又意味著NO。FRM文件。

所以，如果你想要去清理內存中的表，因為你有這麼多東西，你可以找到一個列表以下...

SELECT TABLE_SCHEMA, ENGINE, COUNT(*) AS count_tables,
SUM(DATA_LENGTH+INDEX_LENGTH) AS size,
SUM(INDEX_LENGTH) AS index_size FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'INFORMATION_SCHEMA')
AND ENGINE = "MEMORY" GROUP BY TABLE_SCHEMA, ENGINE;

一如往常... 請查看您的需求，什麼工作最適合你和你的應用程序的基準。

透視表的例子在MySQL

Original post: http://anothermysqldba.blogspot.com/2013/06/pivot-tables-example-in-mysql.html

有人問我如何建立一個訂閱表來跟踪課程等上forums.mysql.com網站

這是比較容易在這裡發布完整的示例，它是一種快速簡單的例子，但你的想法。

這裡的概念是很簡單的。
我們存儲信息的行，我們可以再拉回來時需要到不同的列。

要求學生和課程認購....

首先，我建立了一些表和數據...


CREATE TABLE `details` (
`details_id` int(11) NOT NULL AUTO_INCREMENT,
`details_label` varchar(100) DEFAULT NULL,
PRIMARY KEY (`details_id`)
) ENGINE=InnoDB;
INSERT INTO details VALUES (1,'First Name') , (2, 'Last Name') ;

CREATE TABLE `subjects` (
`subject_id` int(11) NOT NULL AUTO_INCREMENT,
`subject` enum('History','English','Geography','Mathematics','Science','Social Studies','Foreign Languages','Visual and Performing Arts') DEFAULT NULL,
`subject_detail` varchar(255) DEFAULT NULL,
PRIMARY KEY (`subject_id`)
) ENGINE=InnoDB;
INSERT INTO subjects VALUES (1,'Mathematics', 'Algebra') , (2,'History', '1826-1926') , (3,'Geography', ' Africa Studies') ;

CREATE TABLE `student` (
`student_id` int(11) NOT NULL AUTO_INCREMENT,
`email` varchar(150) DEFAULT NULL,
`student_key` varchar(20) DEFAULT NULL,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`student_id`)
) ENGINE=InnoDB;
INSERT INTO student (`student_id` ,`email`,`student_key`) VALUES (1,'foobar@gmail.com','iasdjf');

CREATE TABLE `student_details` (
`student_details_id` int(11) NOT NULL AUTO_INCREMENT,
`student_id` int(11) DEFAULT 0,
`details_id` int(11) DEFAULT 0,
`details_value` varchar(255) DEFAULT NULL,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`student_details_id`)
) ENGINE=InnoDB;
INSERT INTO student_details VALUES (NULL,1,1,'John',NOW()) , (NULL,1,2,'Smith',NOW()) ;

CREATE TABLE `courselist` (
`courselist_id` int(11) NOT NULL AUTO_INCREMENT,
`student_id` int(11) DEFAULT 0,
`subject_id` int(11) DEFAULT NULL,
`status` enum('Waitlisted','Subscribed','Denied') DEFAULT NULL,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`courselist_id`)
) ENGINE=InnoDB;
INSERT INTO courselist VALUES ( NULL,1, 1 , 'Waitlisted' , NOW() ) , ( NULL,1, 2 , 'Subscribed' , NOW() ) , ( NULL,1, 3 , 'Denied' , NOW() ) ;

首先是拉學生的信息：


> SELECT s.student_id , d.details_label , sd.details_value
-> FROM student s
-> INNER JOIN student_details sd ON s.student_id = sd.student_id
-> INNER JOIN details d ON sd.details_id = d.details_id;
+------------+---------------+---------------+
| student_id | details_label | details_value |
+------------+---------------+---------------+
| 1 | First Name | John |
| 1 | Last Name | Smith |
+------------+---------------+---------------+
2 rows in set (0.00 sec)

我們可以挖掘更多的，不斷增加信息...


> SELECT s.student_id , d.details_label , sd.details_value , c.status, j.subject, j.subject_detail
-> FROM student s
-> INNER JOIN student_details sd ON s.student_id = sd.student_id
-> INNER JOIN details d ON sd.details_id = d.details_id
-> INNER JOIN courselist c ON s.student_id = c.student_id
-> INNER JOIN subjects j ON j.subject_id = c.subject_id
-> ;
+------------+---------------+---------------+------------+-------------+-----------------+
| student_id | details_label | details_value | status | subject | subject_detail |
+------------+---------------+---------------+------------+-------------+-----------------+
| 1 | First Name | John | Waitlisted | Mathematics | Algebra |
| 1 | Last Name | Smith | Waitlisted | Mathematics | Algebra |
| 1 | First Name | John | Subscribed | History | 1826-1926 |
| 1 | Last Name | Smith | Subscribed | History | 1826-1926 |
| 1 | First Name | John | Denied | Geography | Africa Studies |
| 1 | Last Name | Smith | Denied | Geography | Africa Studies |
+------------+---------------+---------------+------------+-------------+-----------------+
6 rows in set (0.00 sec)

這是非常有用的或乾淨的，雖然...
所以重做拉正是我們想要的...


> SELECT s.student_id ,sd1.details_value as FIRST_NAME, sd2.details_value as LAST_NAME, c.status, j.subject, j.subject_detail
-> FROM student s
-> INNER JOIN student_details sd1 ON s.student_id = sd1.student_id AND sd1.details_id = 1
-> INNER JOIN student_details sd2 ON s.student_id = sd2.student_id AND sd2.details_id = 2
-> INNER JOIN courselist c ON s.student_id = c.student_id
-> INNER JOIN subjects j ON j.subject_id = c.subject_id
-> ;
+------------+------------+-----------+------------+-------------+-----------------+
| student_id | FIRST_NAME | LAST_NAME | status | subject | subject_detail |
+------------+------------+-----------+------------+-------------+-----------------+
| 1 | John | Smith | Waitlisted | Mathematics | Algebra |
| 1 | John | Smith | Subscribed | History | 1826-1926 |
| 1 | John | Smith | Denied | Geography | Africa Studies |
+------------+------------+-----------+------------+-------------+-----------------+
3 rows in set (0.00 sec)

订阅：评论 (Atom)

另一個MySQL DBA

Pages

2013年6月29日星期六

這麼好笑分享...

2013年6月16日星期日

備份和恢復MySQL的腳本使用Percona的innobackup Xtrabackup

2013年6月14日星期五

max_binlog_cache_size

2013年6月13日星期四

MariaDB的10.0.3 Alpha安裝在Fedora 17 x86_64的

2013年6月12日星期三

MySQL < 5.5 replication to MySQL 5.6

2013年6月10日星期一

Percona的Xtrabackup / innobackupex備份和恢復進程

2013年6月9日星期日

最近翻譯錯誤

百勝安裝MariaDB的/ MySQL的災難，但固定的

2013年6月8日星期六

透視表“或”否透視表

內存和臨時表

透視表的例子在MySQL