タグ付けされた質問 「mysqldump」

完全に再同期した後、スレーブサーバーで「PRIMARYキーの重複したエントリ」が表示される理由を教えてください。 基本的に、「mysqldump」はほぼ一晩実行されていたため、復元プロセスには数時間かかったので、スレーブを起動したとき、マスターから約63874秒遅れていました。 スレーブサーバーは読み取り専用（read_only）であり、再同期プロセス中に書き込みがなかったため、重複したキーがある理由がわかりません。 マスターでバイナリログ形式がMIXEDに設定されています。 DBのバックアップに使用されるコマンド： mysqldump --opt --single-transaction -Q --master-data=2 db | bzip2 -cz > db.sql.bz2 スレーブは、次のオプションを使用して、マスター（db-> db_backup）から1つのデータベースのみを複製します。 replicate-wild-do-table = db_backup.% replicate-rewrite-db = db->db_backup

9 mysql  replication  mysqldump 

mysqldumpを使用してダンプを取得しました。 mysqldump -u... -p... mydb t1 > mydb_table.sql 次に、同じテーブルを持つがレコードが異なる別のデータベースにダンプをインポートしました。 mysql -u...-p... mydb < mydb_tables.sql インポートデータベースには、primary_key 1から1000までのレコードがあり、エクスポートデータベースには、5000〜10,000のレコードがありました。 しかし、インポート時に既存のレコード、つまり1〜1000が削除されました。 どうやって？？なぜ？？これがデフォルトの動作である場合、次回ダンプを発生させないためにダンプにどのようなオプションを指定できますか。

9 mysql  backup  mysqldump  import 

InnoDBのいくつかの問題のため、すべてのデータベースを新しいサーバーにダンプします。 mysqldump -E -R --all-databases | pv -b | mysql -u root -p -h new.server ダンププロセスはエラーで停止しました： 59.9kB assword: 59.9kB ERROR 145 (HY000) at line 2970: Table './mysql/proc' is marked as crashed and should be repaired 228MB mysqldump: Got errno 32 on write 次のコマンドを実行して、すべてのデータベースのすべてのテーブルを修復しました。 mysqlcheck --auto-repair --all-databases mysql.procステータスを調べると、次のことがわかります。 mysql> check table …

9 mysql  stored-procedures  mysqldump  crash 

MYSQLデータベース（ibdata1）のサイズは73 GBで、Windows 2008 O / SでINNODBテーブルの専用データベースサーバーとして実行するように構成されています。mysqldumpを使用してバックアップを実行していますmysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert- set-charset-圧縮--log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql バックアップファイルProddb0635.sqlは、データベースサーバーとは別のサーバーに保存されます。RAMは12 GBです。INNODBバッファープールのサイズは6 GBです。追加のmem.poolは32 MBです。クエリキャッシュのサイズは2 GBです。ネットバッファーの長さは最大16 Mです。パケットサイズ1 GB。 mysqlのバージョンは5.0.67です。 バックアップが実行されていない場合、ユーザーはパフォーマンスに満足しています。 バックアップの実行中にINNODBバッファープールのヒット率が100％に近い高い値になっています。保留中の読み取りまたは保留中の書き込みはありません。innodb wait freeは0です。CPU使用率は高くありません。最小9％から最大15％mysqlbackupが実行されているかどうかに関係なく、クエリキャッシュヒット率は約40％と低くなっています。現在、Windowsタスクマネージャーは、10 GBのRAMが使用されていることを表示しています。2 GBのRAMしか利用できない状態でクエリキャッシュを増やす必要がありますか？mysqlld-ntは9.2 GBのRAMを使用し、mysqldumpは5 MBのRAMを使用しています。Alos氏は、-compressオプションの有無にかかわらず、ダンプファイルのサイズは同じであることに注意しました。 iNNODBバッファープールのサイズを減らす必要がありますか？ …

9 mysql  backup  mysqldump  mysql-5 

すべてのテーブルに対して作成されたスキーマと主キー、FK、インデックス制約を持つ新しいデータベースがあります。mysqldumpを使用して既存のデータベースからデータのみをダンプし、値のみをインポートして他のすべてを除外する方法を教えてください。

9 mysql  mysqldump 

大規模な.sqlファイルに、大きな値を挿入する...値...ステートメントがあります。これらのステートメントの多くは、実行中に警告を生成しています。mysqlに警告を出力させるにはどうすればよいですか？ control-Cを押すと、インポートが停止し、OSのコマンドラインに戻ります。 SQLの実行からの出力例は次のとおりです。 Query OK, 9827 rows affected, 5403 warnings (0.20 sec) Records: 9827 Duplicates: 0 Warnings: 5403 Query OK, 9859 rows affected, 5247 warnings (0.20 sec) Records: 9859 Duplicates: 0 Warnings: 5247

9 mysql  backup  mysqldump 

MyDumper 0.6.1は新しいオプションを追加します--use-savepoints。マニュアルから、それは意味します： セーブポイントを使用してメタデータのロックの問題を軽減します。SUPER権限が必要です 分からない。「メタデータのロックの問題を軽減する」方法と、「SUPER特権」が必要な理由 私が思うに、メタデータは他のDDL変更テーブル構造を防ぐために不可欠です。

8 mysql  mysqldump 

CentOSサーバーがあり、/ var / lib / mysql /は125GBです（ディスクには1GBの空き容量があります）。 通常、mysqldumpを使用してデータベースをバックアップしますが、通常はそのような大きなデータベースを操作しないため、データベースを新しいサーバーにコピーする最も安全な方法を知る必要があります。 すべてのアドバイスに感謝します！

8 mysql  backup  mysqldump 

私はすでにこれを少し調べました。Stack Overflowにも同様の質問があることに気づき、Amazon自身もここに助言を提供する有用なドキュメントを持っています。 http://aws.amazon.com/articles/2933 私の懸念は次のとおりです。 Amazonではmysqldump、「1 GB未満」と定義されている「少量のデータ」のみに使用することを推奨しています。移行しようとしているデータベースが20GBを超えています。 mysqldumpただし、の良い点の1つは、--single-transactionフラグがあることです。これにより、特定の時点と一貫したDB状態を確保できます。 大量のデータの場合、Amazonの推奨は、データベースをフラット（CSVなど）ファイルにエクスポートし、それを使用mysqlimportしてそれらをRDSにインポートすることです。ただし、これを行う方法を知る最良の方法は、SELECT ... INTO OUTFILE一度に1つのテーブルのみを操作するコマンドを使用することです。もちろん、これの欠点は、の一貫性が保証されないことです--single-transaction。 DB全体を一時的に停止することで一貫性を確保できると思います。でも、なるべく避けたいです。 大容量（> 20GB）データベースをフラットファイルにして使用できるようにする最良の方法は何mysqlimportですか？ それが実際にSELECT ... INTO OUTFILEコマンドである場合、データベース内のすべてのテーブルをエクスポートするにはどうすればよいですか（一度に1つずつ実行する必要がないことが望ましい）。 このすべてを通して一貫性を確保するための良い方法はありますか？

8 mysql  mysqldump 

MySQL innoDBには約12のテーブルがあり、そのうちの1つに1100万のレコードがあります。 私はこのコマンドを使用して物事をバックアップしました： mysqldump -u [USERNAME] -p [DBNAME] | gzip > [/path_to_file/DBNAME].sql.gz そして、次のコマンドで新しいサーバーにインポートします。 USE [DBNAME]; SOURCE [/path_to_file/DBNAME].sql; ここに私が苦しんでいる痛みがあります（時間は各クエリで上がっています！）： スピードアップするにはどうすればよいですか？mysqldumpコマンドに何か問題がありますか？

8 mysql  backup  mysqldump 

MyISAMとInnoDBの両方を使用するMySQLデータベースの論理バックアップについて質問があります。 mysqldumpユーティリティは、これらの2つのオプションがサポートされています。 --single-transaction-すべてのテーブルを単一のトランザクションでダンプすることにより、一貫したスナップショットを作成します。マルチバージョニングをサポートするストレージエンジンに格納されているテーブルに対してのみ機能します（現在はInnoDBのみがサポートしています）[...]オプションは自動的に--lock-tablesをオフにします。 -x、-lock-all-tables-すべてのデータベースのすべてのテーブルをロックします。これは、ダンプ全体の期間中、グローバルな読み取りロックをとることによって実現されます。--single-transactionと--lock-tablesを自動的にオフにします。 InnoDBには、 --single-transaction MyISAMには、lock-tablesまたはlock-all-tablesが必要です（データベース間の整合性が必要な場合）。 それでは、ハイブリッドデータベース（MyISAMエンジンとInnoDBエンジンの両方を使用するデータベース）はどのようにバックアップされることになっていますか？ 編集： 明確にするために、質問は次のように再定式化できます。 lock- [all-] tablesオプションはInnoDBテーブルの一貫したバックアップを保証しますか？

8 mysql  innodb  mysqldump  myisam 

次のコマンドを使用してのみ、ストアドプロシージャをダンプしています。 mysqldump --routines --no-create-info --no-data --no-create-db --skip-opt databasename -u username -p > outputfile.sql ただし、結果のダンプファイルには、各プロシージャ宣言の前にDROP PROCEDURE IF EXISTSは含まれていません。 ダンプクエリをダンプに追加するにはどうすればよいですか？ ありがとうございました。

8 mysql  backup  stored-procedures  mysqldump  dump 

mysqldumpを使用して、バックアップ用のフラットファイルを作成します。このファイルを使用して、代替サーバーでデータベースを再作成しました。コマンドラインでsshを使用してインポートプロセスを実行したところ、複数のPacket too Largeエラーが発生しました。 より大きなmax_allowed_pa​​cket（つまり、1000M）でmysqlを再起動しても、エラーが発生しました。インポートファイルでmax_allowed_pa​​cketを設定しようとしても、エラーが発生しました。 max_allowed_pa​​cketが設定されていることを確認する方法や、この問題を引き起こさないファイルを作成するmysqldumpを使用する方法はありますか？ 参考のために： 非圧縮のmysqldumpファイルは〜2GB データベースタイプはINNODBです

8 mysql  backup  mysqldump  mysql-5