営業日はゆっくりでしたが、確実に終わりました。 日光がブラインドを通り抜け、金色のscar色でオフィスをあふれさせました。 角のどこかで、コーヒーマシンが賑やかになり、カプセルから残りのコーヒーを絞りました。 私たちのプロジェクトは、デザイナーとアニメーションで何かを話し合ったので、私はジュニアプログラマーが親切に私に任せた判決を下しました。
そして、「Tサイトはどうですか？」というメッセージがなければ、すべてがうまくいくようです。
私の良き友人の一人が、私たちのサイトの1つが正しく表示されていないことを知り、私に知らせました。
私はすべてのものを落とし、サイトにページをロードしました。 問題はありませんでした。 まあ、おそらく少しの再設計が必要でした...
「すべてがサイトで正常に機能している」と私は友人に書き、再びコードとバグの魅惑的な世界に飛び込んだ。
それからしばらくして、私の脳は私の記憶から私の友人の警報信号を取り去り、私は意図せずに登ってサイトを再確認しました。 何らかの理由で、サイトのパフォーマンスに自信を持って、私はわずかな自信を経験しました。
このサイトのメインページでは、残念ながらエンコードが失われ、CSSが完全に欠けていました。 処女白の背景にあるアブラカダブラの黒いシンボルは、私を現実に戻しました。 自信はすぐに消え、私は熱心にキーボードのCTRL + F5を押し始めました。
「それはただのキャッシュです...はい...ただのキャッシュです...」私は何度も何度も自分自身に繰り返しました。
ブラウザーのキャッシュをリセットする10回目の試行で結果が得られず、サイトのメインページが大切なキーをクリックするたびに外観が変化し続けることに気付いたとき、最初に思い浮かんだのは「ハック？！」でした。 次のページのリロード後、そのようなテーブルが見つからなかったという赤と白の碑文を見たとき、私の恐怖は強くなり始めました。
手自身がサイトに関連するすべてを変更するために着手し、管理パネル、データベース、SSHにアクセスします。
その後、ログを注意深く調べ始めました。 しかし、ログは大声で言われています。 私が自由に使えるのは、Webサーバーの動作に関するレポートのみでした。 共有ホスティングでは、SSHを介したMySQLの失敗と失敗した認証試行のログは発行されません。
ログには奇妙なものは何も見つかりませんでした。MySQLに直接接続するために、SSHコンソールに直接アクセスしました。サイトがデータベースにテーブルがないことで呪われていることをはっきりと覚えているからです。
非常に奇妙ですが、すべてのテーブルが配置されていました（少なくともサイトが呪われたテーブルは正確に配置されていました）。
CMSとして、サイトTで1C-Bitrixが使用されます。 私たちはこのシステムが非常に好きで、あらゆる点でそれを賞賛します（まれな例外はあります）。
サイトの設定に入ると、まったく無関係のサイトRからデータを見たときの驚きを想像してください。ルートへのパス、ドメイン名、その他の設定が変更されました。 驚いた私は、目を大きく開けてモニターを見て驚きました。 同時に、私の後ろのどこかで、私たちのプロジェクトはすでにバレリアンチンキを注いでいた。 何らかの理由で、F5を押しました。 その後に起こったことは、私を最も深いショックと落胆に陥れました。 サイトの設定は通常の値に戻りました。
この瞬間、一瞬、IT業界全体の妥当性を疑い、奇跡を信じ始めました。 妻の電話が私を困惑させました。 私は電話を取りました。 彼女が私に言ったことを今でも思い出せません。なぜなら、神秘的な何かの感覚が私を離れず、私の脳は必死に少なくとも何が起こったかの説明を見つけようとしていたからです。
電話に何かをつぶやいて電話を切った。 さて、少なくとも私は何かを確信しています。 自宅では、自分に関する多くの興味深い情報を見つけられると確信しています。
しかし、そして今、私たちは何が起こっているのかを理解する必要があります。
設定ページの次のリロード後、私は再び他の人々の価値を見ました。
Webサーバーのルートフォルダーへの絶対パスから判断すると、同じホストにあるサイトの設定を登録しました。
私はすぐに電話で携帯電話を感じ、ホスティングの技術サポートに電話しました。
会話から、彼らは私たちの問題を今すぐ解決できないことが明らかになりました。 テクニカルサポート担当者は、私に電子メールでアピールする必要があることを丁寧に明らかにし、私の要求はライブターンの順序で24時間以内に検討されます。 私が考えているすべてのことを丁寧に彼らに表明した後、私は電話を切って、彼らに敬意を込めた手紙を書きました。 念のため、テクニカルサポート1C-Bitrixにも手紙を書きました。
オフィスの完全な沈黙は、大きな壁時計のカチカチ音と、システムユニットの冷却システムのほとんど聞こえないノイズによってのみ破られました。 オフィスでいくつかの機能を実行する白い円形の時計。 まず、それらは内部の要素でした。 私たちのオフィスの家具はそれほどではありません。 大きくて柔らかいソファを買うことは絶対に気にしないので、仕事の合間に、コーヒーを片手に横になり、足を伸ばして、いつかウェブサイトの開発から離れて面白い開発を始める夢に飛び込むことができますそしてもちろん、ゲームプレイ、ゲームの面で革新的です。
第二に、この真っ白な丸い時計は、本来の機能を果たしていました-時間を示しました。 誰かが時間を知る必要がある場合、彼は確かにこの時計に目を向けました。 彼らはいくつかの不可解な、ほとんど催眠の魅力を持っています。 そして、手元のスマートフォンやモニター画面に時計があることを誰も気にしませんでした。
ですから、その瞬間、私たちの教訓的な監督は、秒針の各ステップで容赦なく時間を数えました。
そして、私たちは皆、それを待っていました。今、私たちのメールサーバーは、いくつかのテクニカルサポートから待望の応答を受け取ります。
しかし、まだ手紙はありませんでした。 どんな仕事にも疑問はありませんでした。 灰白質を追いかけている私の脳は、この奇妙な変態をサイトTで解明しようとしました。
この状態のサイトが訪問者に見られた場合、彼らは明らかに幸せではないことを理解し、私はそのサイトを公開アクセスから閉じました。 さらに、ハッキングが発生した場合、Cookieを盗むためにサイトがすでに注射でいっぱいになっている可能性が非常に高いため、このサイトにアクセスすることは絶対に禁忌です。
メインモジュールの設定で大切なボタンを押した後、サイトは一時停止したアニメーションに突入しました。
好奇心から、私はサイトRに行きました。サイトRの設定は、サイトの設定で詳しく説明されています。
「建設中のサイト」-サイトRのメインページに誇示されています。
脳は最後の2つのイベント間の接続を確立しようとし、サイトTへのアクセスを再び開きました。
再びサイトRを訪れたとき、彼は作業能力を回復したことがわかりました。
偶然か依存か？
メインモジュールの設定で操作を繰り返すと、サイトTに対するサイトRの依存関係、およびその逆の関係があると確信しました。
しかし、これはどのようにできますか？
TサイトとRサイトが接続されているものはすべてホスティングです。
「そして、Rウェブサイトにリストされている電話番号に電話して、状況を説明してみましょう」-予想外に、私たちのプロジェクトは提案しました。
このアイデアの才能を感じる時間がある前に、突然電話がオフィスで鳴りました。
チューブの最後に、Rサイトを開発した人たちがいましたが、現在イベントのために迷っています。
彼らは私に電話を渡した。
短い会話の後、彼らは私たちのように、何が起こっているのかについて何も知らないことがわかりました。
「どうやら、ホスティングでは、奇妙な方法で、2つの拠点の間にシンボリックリンクがあります」と私は提案しました。
さて、ここで他にどのような説明が見つかりましたか？ 両方のデータベースへのアクセスは異なりますが、奇妙な方法で、データベースの変更は私たちに影響を及ぼし、その逆も同様です。
「別のデータベースを作成してみましたか？」私は続けました。
「はい、これは3番目です」彼らは電話の反対側の声で悲しく私に答えた。
したがって、シンボリックリンクを持つオプションには水がかかりませんでした。
それらの人々はまた、ホスティングの技術サポートに訴えを書きました。 名前、スカイプ、電話番号を交換し、お互いを最新の状態に保つことに同意しました。
ホスティングのテクニカルサポートからのニュースはありませんでした。 私は再び彼らの番号にダイヤルし、状況が行き詰まっていて、同じ問題が2つのホスティングアカウントですでに観察されていることをテクニカルサポートの従業員に説明し始めました。
私は応答でわかりやすいものを聞きませんでした。 意味のない決定的な会話の終わりに、私はついにホスティングの技術サポートが私たちを助けないだろうと確信しました。
少なくとも、これがハックではないことは明らかでした。
その瞬間から、ホスティングの技術サポートを望みなくなり、すべてを自分の手に委ねました。
1C-Bitrix管理パネルから表のリストにアクセスすると、質問に対する回答が得られるとのことです。 実際、検索を開始する場所から他のオプションはありませんでした。
サイト設定が保存されているb_langテーブルのコンテンツとサイト設定の管理ページのコンテンツが異なることを発見したとき、私は前者に劣らず驚きました。
なんてこった！ これはどうして？
「そのうちの2つがあります！」-私の頭からフラッシュしました。
「データベースには2つの接続があります」-私はこの考えにどんどん固まっていきました。
管理パネルにはあるものが表示され、テーブルの内容には別のものが表示されることを他にどのように説明できますか？
このアイデアをもう少し開発
して、データベースへの永続的な接続について思い出し
ました 。
ただし、永続的な接続の技術の説明から判断すると、データベースに接続するときは少なくともユーザー名とパスワードで区切られ、サイトRとTのこのデータは異なります。
それでも、キャッシングシステムは何らかの方法で接続を記憶し、2つの完全に異なる接続でそれを提供できますか？
この瞬間までに、私は何でも信じる用意ができていました。
1C-Bitrix設定でパーマネント接続機能をオフにし、同時に、キャッシュタイプを空のままにしました（値が存在する前に「APC」）。
不幸な同僚に同じことをするように頼みました。
すべての準備が整ったら、F5を押しました。 これらは私の人生で最も長く、最も刺激的な秒でした。 まあ、それは簡単なことではありません。
最後に、ページが読み込まれ、...サイトが機能しました！ サイトRも大丈夫でした。 すべてが正常かどうかを確認する方法は1つしかありませんでした。 メインモジュールの設定に入り、サイトを「建設中」状態に再度送信しました。 サイトTはこの指示に従い、サイトRは引き続き稼働しています。 この事実は、問題が正常に解決され、ベースが相互接続されなくなったことを示しています。
しかし、問題は何ですか？ 永続的な接続またはキャッシングですか？
問題は、まったく接続されていないサイトにAPCキャッシュがあったことであることがわかりました。
dbconn.phpファイルの1C-Bitrixは、次のテーブルを強制的にキャッシュします。
- b_file
- b_file_bucket_size
- b_lang
- b_option
- b_lang_domain
- b_site_template
- b_event
- b_agent
リストは異なる場合があります。
他のテーブルの中でも、サイト設定が保存されている同じb_langがここにはっきりと表示されています。 したがって、TサイトとRサイトは交互にこのテーブルにデータを記録し、APCにキャッシュしました。 サイトRがテーブルをキャッシュすると、サイトTはキャッシュされたコピーを取り、その逆も同様です。
しかし、ここに主な質問があります-数千の作業アカウントを持つホスティングでキャッシュを混合することはどのように可能ですか？
結局のところ、APCを使用するサイトは、特定のホスティング（より正確には、サーバー）内の（ほぼ）他のサイト（APCも使用）の動作を混乱させる可能性があります。
その結果、何でもキャッシュできるため、サイトのダウンタイムと、おそらくデータ盗難による損失が発生します。
このようなホスティングロジックは正常ですか？
Rサイトの開発者との短い議論の後、サイトに異なるBX_CACHE_SIDを簡単に設定できるという結論に達しました。
Tサイトは約1年半このホスティングに取り組んでおり、この種の苦情は発生していないため、明らかに問題があります。 そして、突然そのような事件。
キャッシュがRサイトと混ざったのはなぜですか？
このような大規模なホスティングで異なるアカウントのキャッシュを区切るメカニズムがないのはなぜですか？
これらの質問で私は家に帰りました。 彼らは夕方まで私の頭を離れませんでした。
敷居で私は心から迎えられました。私と妻はもう会いたくなかったので、テーブルの上に熱くて食欲をそそるにおいのする夕食がありました。
「この誤解は終わりました」と私は安心して思いました。
はい、いつか必ずゲームに参加します...
UPD 1：コメントを検討した後、上記のすべての簡単な要約を提供する必要があるという結論に達しました
常に一意のキャッシュIDを設定し、定期的にバックアップするUPD 2：ホスティングのテクニカルサポートとのコミュニケーションの結果、アカウントのキャッシュを共有するサービスをまったく提供していないことが判明しました。
彼らはテクニカルサポートのディレクターに連絡しました。このディレクターにホスティングの希望を送ることができます。
UPD 3：ホスティングのテクニカルサポートサービス
の責任者は、アカウントキャッシュの分離を提供する新しいホスティング環境の開発に関する素晴らしい情報を共有しました。