問題タブ [availability]

CAP 定理について私がこれまでに読んだすべてのことによると、可用性、一貫性、分断耐性の 3 つすべてを提供できる分散システムはありません。

現在、Hadoop 2.x では、Hadoop クラスターにあった単一障害点 (単一の名前ノード) を取り除くために構成できる新しい機能が導入されました。これにより、クラスターは可用性が高く、一貫性があり、分断耐性が高くなります。私は正しいですか？または、何か不足していますか？CAP によると、システムが 3 つの機能すべてを提供しようとする場合、レイテンシの代償を払う必要がありますが、新しい機能はこのレイテンシをクラスタに追加しますか? それとも、Hadoop は CAP 定理を破ったのでしょうか?

仮想マシンで実行されている分散アプリケーションがあり、そのうちの 1 つのサービスがアクティブ/パッシブ モードで実行されています。アクティブな VM は、パブリック IP を介してサービスを提供します。アクティブ VM に障害が発生すると、パブリック IP がパッシブ VM に移動され、パッシブ VM がアクティブになり、サービスの提供を開始します。

このパターンは、kubernetes によって管理されるコンテナー化されたアプリケーションにどのように適合しますか?

レプリカ = 1 のレプリケーション コントローラーを使用すると、ノード/ミニオンに障害が発生した場合、レプリケーション コントローラーは別のミニオンでポッド (= 現在のアプリケーションの VM) を再スケジュールしますが、これは現在のソリューションと比較してダウンタイムが長くなる可能性があります。 IP リソースのみが移動されます。

レプリカ = 2 のレプリケーション コントローラーを使用する場合、アンチパターンである 2 つのポッド (1 つはパブリック IP を使用し、もう 1 つはパブリック IP を使用しない) で異なる構成が必要になりますか? さらに、kubernetes には仮想 IP をサポートするための設計された方法はありません (ポッドを移動します)?

または、レプリカ = 2 を使用して、IP を管理するために自分で何かを実装する必要があります (または、ペースメーカーを使用する可能性がありますか?これにより、別の問題が発生します: アプリケーション、kubernetes、およびペースメーカー/corosync でクラスター管理が必要になります)。

それで、これはどのように行われるべきですか？

在庫管理なしで、在庫状況に関係なくすべての商品を表示したいMagentoストアを運営しています。

在庫管理をオフにして、必要なものをすべて表示しましたが、検索結果、カテゴリ、およびブランド ビューから「在庫状況: 在庫あり」メッセージを削除する方法が見つかりません。これを表示しないようにするにはどうすればよいですか?

style.css ファイルの編集を見つけましたが、これは製品ページからのみ削除され、検索結果、カテゴリ、ブランド リストからは削除されません。

私は、顧客が次の予定を予約するために選択できる予約時間を見つける必要があるクライアント用のオンライン予約システムを開発しています。

現在のデータベース設定について説明します。

テーブル名:予定- これらは、顧客が現在予約している予定です。

テーブル名: staff - スタッフのリスト、彼らが働く曜日、関連する日のシフトの開始時刻と終了時刻。

テーブル名:治療- 利用可能な治療のリスト

テーブル名: staff Treatments - どの治療がどのスタッフによって実行されるかを識別するためのルックアップ テーブル。

したがって、治療 1 はスタッフ メンバーのリサによって実行されると想定できますが、リサは水曜日の午前 9 時から午後 5 時までと金曜日の午前 9 時から午後 6 時までしか勤務していません。Phil は治療 1 も実行できますが、月曜日の午前 9 時から午後 5 時までしか実行できません。

私のアプリケーションでは、ユーザーが予約しようとしている治療法を尋ねています。たとえば、90分間続くトリートメント1。次に、顧客は予約を希望する日付を選択します。したがって、この段階で、必要な予約の時間の長さと日付、その後の曜日がわかります。

選択した日付を取得し、次の 5 日間、毎日ループします。

事前に予約された予定を含む予定テーブルに基づいて、顧客が選択できるすべての利用可能な時間帯を表示できるクエリを開発しようとして立ち往生しています。

顧客が 8 月 24 日にトリートメント 1 を予約したいとします。リサは金曜日の午前 9 時から午後 6 時まで勤務していることがわかっていますが、すでに午前 9 時から午後 12 時までの予定があります。

治療は 90 分なので、最終的に次のようなデータが必要です。

ただし、次の問題は、利用可能な部屋が4つしかないため、同時に4つ以上のトリートメントを予約できないことです。

この投稿を見ました - Finding free blocks of time in mysql and php?

しかし、私の退職はもう少し複雑で、クエリの作成方法がわかりません。どんな助けでも大歓迎です。

構造にいくつかの変更を加えました。私のクエリは次のとおりです。

次のデータを使用します。

と

返されるデータは次のとおりです。

ただし、予約日は表示されず、Null 値のみが表示されます。

何か案は ？

私が知る限り、Azure DB を廃止された層から新しい層にスケーリングするには、Azure portal のスケール機能を使用するだけです。

私がどこにも見つけられないように見えるのは、廃止された層から新しい層にスケーリングするときに、接続文字列の変更が必要かどうか (または、使用できなくなる可能性があるその他の問題) があるかどうかについての決定的な答えです。

アップグレードが必要な本番データベースがあります。サービスの中断は非常に悪いことです。