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!

今私たちは最初の増分ディレクトリを適用できます。 あなたがincremental_1ディレクトリが今fullbackupディレクトリに適用されていることを以下の例に見ることができます。 これは、以前のケースではなかった。

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-アルfullbackup /

合計20520

をdrwxr-xr - xに。 7ルートルート4096 6月9日午後3時58分。

を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日15時58分ibdata1を

をdrwxr-xr - xに。 2ルートルート4096 6月9日15時58 incremental_1

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後03時41分のmysql

をdrwxr-xr - xに。 2ルートルートperformance_schema 4096 6月9日午前15時41分

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分Start_Of_Demo

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分の世界

-RW-R - rを - 。 1ルートルート13 6月9日夜03時41 xtrabackup_binary

-RW-R -----。 1ルートルート89 6月9日午前15時58 xtrabackup_checkpoints

-RW-R -----。 1ルートルート2097152 6月9日午後3時58 xtrabackup_logfile

今私たちは第二インクリメンタルディレクトリを適用してみましょう。 あなたがincremental_2ディレクトリが今fullbackupディレクトリに適用されていることを以下の例に見ることができます。 これは、以前のケースではなかった。

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 / local / srcに/ fullbackup / Start_Of_Demo / db.opt 'へ

130609夜04時00分09秒innobackupex：完成したOK！

[ルート@ Fedora64 SRC]＃LS-アル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日午後03時41分のmysql

をdrwxr-xr - xに。 2ルートルートperformance_schema 4096 6月9日午前15時41分

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分Start_Of_Demo

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分の世界

-RW-R - rを - 。 1ルートルート13 6月9日夜03時41 xtrabackup_binary

-RW-R -----。 1ルートルート89 6月9日午前16時00 xtrabackup_checkpoints

-RW-R -----。 1ルートルート2097152 6月9日午後3時58 xtrabackup_logfile

今私たちはフルバックアップディレクトリを適用してみましょう。 あなたがincremental_2ディレクトリが今fullbackupディレクトリに適用されていることを以下の例に見ることができます。 これは、以前のケースではなかった。

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

[ルート@ Fedora64 SRC]＃innobackupex - コピーバックは/ usr / local / srcに/ fullbackup /

[ルート@ Fedora64 SRC]＃chownは-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 |

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

参考のために利用可能なリンク。

• http://dev.mysql.com/doc/index-other.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/creating_a_backup_ibk.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/incremental_backups_innobackupex.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/partial_backups_innobackupex.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/restoring_a_backup_ibk.html

変換エラー最近

それは最近、本ウェブサイト上の変換エラーが発生したことが表示されます。
このような理由から、私は本当に申し訳ありませんが、私はそれが再び起こらないように努めていきます。
それでも問題がある場合は私に知らせてください。

yumをインストール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


[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
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 /]#

OKだから私は、mysqldを停止しなくても、それを始めた - スキップ·助成金、それはちょうどそれをインストールし、結局、私はまだパスワードを設定していない。

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


[OK]をので、私は再びそれを試してみましょう...

[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)


だから私は、再び箱に行かなければならない - スキップ·助成金の表は、有効になっており、rootアカウントを更新する

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のファイルが欲しかったときにそれを修正する方法の例の詳細です

ピボットテーブル]または[いいえピボットテーブル

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

このトピックでは、最近になって上に来forums.mysql.comサイト。 

表明意見はピボットテーブルが拡大するのは非常に困難であり、それは代わりにピボットテーブルのスキーマの再設計の価値があるでしょう維持するということでした。 これは有効なポイントで有効な意見です。 

私は私の視点を表現し、他人のためにそれを用意して助けるためにここにトピックを追加したいと思います。 

これは、すべてのピボット·テーブルかどうかを使用する必要がある場合に収集されたデータに依存します。 で与えられた例の以前の記事私が、彼 ​​らがどのように動作するかのほんの一例であった。 

あなたが知られているユーザー情報（最初と最後の名前、アドレス情報、電話番号）を収集している場合は、yesとピボットテーブルは、あなたが必要となるかという、より複雑です。 あなただけの、コア情報の外にそれらを結ぶために、いくつかのデータ·ポイントを持っている場合は、yesを別のテーブルには、ソリューションであり、単純な結合で結ば。 

それはあなたが収集している事業体あたりのデータの動的な量のためのものであるときに、ピボットテーブルのコンセプトは有効です。 
あなたは、100人のユーザーのために10個のデータポイントが必要になる場合があります。 あなたは次の100ユーザーに500のデータポイントが必要になる場合があります。 スキーマは簡単にそれを扱うことができますか？ 

で与えられた例以前の記事私は同意は、ピボット·テーブルを必要としません。 しかし、私はちょうど聞かれる質問に答えるフォーラムで私に与えられた概念を使用していました。 

理想的には、自分のスキーマの両方のソリューションを使用することができます。 コアデータポイント列に保つ。 動的データは、ピボットテーブルに保つ。 

それが正しく構築されている場合、それは非常にスケーラブルであり、私はピボット·テーブルに格納されたデータの十億は簡単に私にこれを証明した。 それはそれはいくつかの作業を必要としないという意味ではありません。 あなたは非常によく他の人がデータを収集するために、ピボットテーブルに見えるいくつかのビューまたはサマリー表を作成することは容易になるだろうことを見つけるかもしれない。 これは、データが最初の場所でそのように保存されていませんでした、なぜ質問を頼む？ 再度、それはあなたのデータとデータを使用するアプリケーションの動的な性質に依存します。 

メモリとテンポラリテーブル

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を 、私は最初の状況を処理する別の方法を考えた。

あなたは一時的な情報を処理するためのテーブルが必要な場合は2つの方法でそれについて移動することができます。 それはセッション処理あたりであれば一つは、あなたは唯一の一時テーブルを作成する必要があります。

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) 

MySQLのチェック表

Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-check-table.html

MySQLのチェックtablesコマンドは、次の操作を実行したい人のために非常に有用である： 

• バージョンの互換性の確認
• データの整合性をチェックする
• アップグレード
• 一般的なテーブルエラー

プロセスは十分に簡単です： 

> show tables;
+-----------------+
| Tables_in_world |
+-----------------+
| City |
| Country |
| CountryLanguage |
+-----------------+

> check table City\G
*************************** 1. row ***************************
Table: world.City
Op: check
Msg_type: status
Msg_text: OK 

これは、エラーの可能性を認識しているように更新滞在するには良い作業です。 一つの可能​​な問題は、このツールは本当にMyISAMとInnoDBテーブルに焦点を当てていないということです。 あなたがInnoDBのためにそれを使用する場合は、QUICKオプション（またはオプションなし）を追加したときに、 "チェック表"コマンドは実際にのみ適用されます。 、CHANGED、FAST MEDIUMとEXTENDEDオプションはすべてのInnoDBは無視されます。 今、あなたが自分を求めている場合、どのようなInnoDBのはどうでしょうか？ なぜMySQLはInnoDBエンジンでデータの整合性を無視するでしょうか？ 深呼吸をしてリラックスし、InnoDBがあるACIDの苦情 、ACIDは" 頭字語の原子性のために立って、 一貫性 、独立性 、および耐久性。 " だから、それはまだあなたのテーブルにいくつかの洞察力か、確認情報を提供できるため、InnoDBテーブルをチェックして無視しないでください。 InnoDBのテーブルが壊れていることになっていた場合、サーバーがデータを保護するためにシャットダウンされていることに留意してください。 あなただけのMyISAMテーブルは、このツールを使ってあなたの降圧のためのより多くの強打を得る。 

うまくいけば、 "OK"、またはそうでなければ、テーブルを修正する修復表を実行する必要があり、 "表が最新既にアップしている"の応答を取得します。 

それでは、私たちが利用できるオプションは以下のとおりですので、頻繁に、簡単にこれを行うことができます。 
下の文書リンクもいくつかのコミュニティ駆動自動オプションを提供します。 スクリプトをプロセスと簡単にすべての結果にテーブルをチェックし適用しテーブルを表示することができます。 あなたのために提供されるツールを使用するにはかかわらず、それはちょうど私に簡単に表示されます。 


$ mysqlcheck -u root -p --databases world --fast
Enter password:
world.City OK
world.Country OK
world.CountryLanguage OK

$mysqlcheck -u root -p --databases world --fast --check-only-changed
Enter password:
world.City OK
world.Country OK
world.CountryLanguage OK 

さて、これは単純で直接的ですが、それはまた、どのようなパスワードについては、別の質問に自分自身を貸す？ 

あなたはちょうどので、あなたのスクリプトやcronジョブにパスワードを入れて持っていないテーブルをチェックするために許可されないパスワードを持つユーザーを作成する必要があります？ あなたにも。mysql_historyファイルの周りに座って、パスワードを持つようにしたい。 だから、もう一度あなたのために利用可能なツールを活用する。 MySQLの5.6を導入MySQLの設定ユーティリティを 。 私は以前のブログ記事でそれを設定する方法の例があります： 
http://anothermysqldba.blogspot.com/2013/05/mysql-users-grants-mysqlconfigeditor.html 

mysqlcheck --login-path=local --databases world --fast --check-only-changed
world.City OK
world.Country OK
world.CountryLanguage OK 

$ mysqlcheckの - ヘルプが使用可能なオプションの完全なリストを提供します。 
さて、あなたは、あなたのすべてのテーブルをチェックするcrontabファイルおよび/またはスクリプトでパスワードを保つことができます。 

ドキュメント： 

• http://dev.mysql.com/doc/refman/5.5/en/check-table.html