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文檔: 


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

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 |
Start_Of_Demo |
incremental_1 |
incremental_2 |
| mysql |
| performance_schema |
world |
+--------------------+

可供參考的鏈接。

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)