MySQLによるユーザーデータの取得例を詳しく解説

何が起こったのか

ある日、当社の外部エリアの営業Cさんが、8月3日以前のワークフロー記録が見つからないと言いました。理由を聞いてみると、WeChatがアップデートされたためだった（当社のワークフローはEnterprise WeChatをベースに開発されている）。分析の結果、WeChat ID はプロセス データとは何の関係もないことが判明したため、当初は WeChat ID を更新するだけでよかったが、その結果、当社のプロセス システム管理者が最初にユーザーを削除し、その後ユーザーを作成したという結論に達しました。新しいユーザー。

解決プロセス

1. 私が最初に考えたのは、スケジュールされたバックアップ データから元のユーザー ID を直接取得することでした。システムは 10 日間のレコードしかバックアップしていないことが判明し、ワークフロー システムはそれを示しました。営業 C は 8 月 3 日のみでした。それ以降のプロセス記録は 40 日以上前のものであり、自動バックアップ データから復元することはできません。

2. したがって、データベース内のバイナリレコードからのみ分析できます。 MySQL データが保存されているディレクトリを入力します:

3. ファイルの変更時間を分析することで、削除操作が mysql-bin.000014 ファイルに記録されていることがわかりました。

4. ログ ファイルはバイナリであるため、ログは SQL ファイルとしてエクスポートされます:

mysqlbinlog --no-defaults mysql-bin.000014 > workflow_operator.sql

5. ファイルを圧縮してローカルにダウンロードすると、ログ レコードは 132M になります。テキスト ツールをローカルで使用して、ユーザーを削除するすべての操作を検索します:

Sales C を削除する最後のアクションは行 127766 にあります (ログ レコードの数は比較的大きいですが、ユーザーを削除するアクションは比較的小さいため、トラブルシューティングは簡単です)

7. 幸いなことに、ユーザーのみが削除されたため、プロセスデータは削除されませんでした。アーカイブされるため)、sales C の古いプロセス データ user_id を新しい user_id に置き換えるだけです。手作業で古い ID を持つテーブルを見つけ、update ステートメントを使用してそれらをまとめて更新しました。 . 最後に、すべてのデータを取得しました:

(プライバシー上の懸念から、最後の 4 桁は XXX に置き換えられました)

tar -czvf workflow_operator.tar.gz workflow_operator.sql

営業 C は、とても喜んでくれて、貴州に行ったらぜひ訪ねてくださいと誘ってくれました

以上がMySQLによるユーザーデータの取得例を詳しく解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。