カテゴリー: 技術系memo

  • Google Cloud SQLのMySQLのタイムゾーンを変更する

    Google Cloud SQLでMySQLのインスタンスを追加すると、タイムゾーンがUTCになる。これを、日本に変える方法のメモ。

    タイムゾーンの確認のSQLと実行例。

    MySQL [(none)]> SHOW VARIABLES LIKE '%time_zone%'
        -> ;
    +------------------+--------+
    | Variable_name    | Value  |
    +------------------+--------+
    | system_time_zone | UTC    |
    | time_zone        | SYSTEM |
    +------------------+--------+
    2 rows in set (0.157 sec)
    MySQL [(none)]>

    変更方法

    1. Google Cloudの管理画面にアクセスして、SQLの管理画面を開く。

    2. 設定変更するインスタンスを開く。

    3. 上部メニューの「開く」をクリックする。

    4. 「フラグ」のところを広げる

    5. 「データベースフラグを追加」をクリックする。

    6. フラグ選択で、「default_time_zone」を選択する。

    7. 値に、「Asia/Tokyo」を入力する(選択ではなくて、入力する)。

    8. 保存する。

    9. 保存後に、インスタンスの再起動が必要になるので、再起動する。

    設定変更後に確認した例。

    システム側はUTCのままだが、アクセスしたとき(セッション)のタイムゾーンは、Asia/Tokyoに変わっており、現在時刻を取得した際の時間も日本時間になっていた。

    MySQL [(none)]> SHOW VARIABLES LIKE '%time_zone%';
    +------------------+------------+
    | Variable_name    | Value      |
    +------------------+------------+
    | system_time_zone | UTC        |
    | time_zone        | Asia/Tokyo |
    +------------------+------------+
    2 rows in set (0.159 sec)
    MySQL [(none)]> select now();
    +---------------------+
    | now()               |
    +---------------------+
    | 2023-12-11 13:50:43 |
    +---------------------+
    1 row in set (0.154 sec)
    MySQL [(none)]>
  • 見積をとると、型落ち機種ばかり出てくる

    とある機器の見積をとると、数年前の型落ち機種の見積ばかりが出てくる。型落ちを指定しているわけでも、コスト制約をしているわけでもない。なぜなんだろうか。

    ぼちぼち販売終息になってもおかしくないくらいのロングセラーの機種で、CPUは4年落ちのXeonばかり。これから数年以上も使うという機器なのに、そんなに古いCPUを勧められる。後継機種が出ていないわけではない。後継機種で、2種も出ているのに、古い機種ばかりだ。これが、1社だけならばよいのだが、複数社(依頼したところ全部)から出てくるのだから、なかなか異常とも言える。在庫がダブついているのだろうか。COVID-19のときに半導体不足になったときに、ちょっと前の型を大量にストックしたりしたのだろうか。とはいえ、納期は即納というわけではなく1〜2ヶ月だから、どこからかは輸送されてくるはず。困るのは、安いと思っても、CPUの型番から、何年にリリースされたものなのかをしっかりとチェックしないと4年前のCPUだったりするということ。1、2年程度の型落ちならばよいが、4年となると・・・PCならば、買い替え時期にあたるくらいの期間だけに安物買の銭失いになりかねないということ。

    いったい、どうしたのだろうか。不思議だ。

  • GitLabo 16.4.0から16.6へは自動アップデートできた

    apt updateで、GitLabo 16.4.0から16.6へは自動アップデートできた。

  • メモ:GitLab CE 16.2からGitLab CE 16.4.1にアップデートした。

    また、小まめにGitLab CEのアップデートをやり忘れて、apt updateでのアップデートでエラーになった。今回は、GitLab CE 16.2から、GitLab CE 16.4.1へのアップデートだ。

    apt upgradeで発生したエラー(一部抜粋)は下記。

    gitlab preinstall: It seems you are upgrading from 16.2 to 16.4.
    gitlab preinstall: It is required to upgrade to the latest 16.3.x version first before proceeding.
    gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
    dpkg: アーカイブ /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
     new gitlab-ce package pre-installation script subprocess returned error exit status 1
    処理中にエラーが発生しました:
     /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb
    E: Sub-process /usr/bin/dpkg returned an error code (1)

    まずは、GitLabのサイトで、アップグレードできるパスを調べる。

    https://docs.gitlab.com/ee/update/index.html#upgrading-to-a-new-major-version

    これによると、一度、16.3.5にアップグレードしてから、この時点の最新にアップグレードする必要があるとのこと。

    アップグレードパス : 16.2 → 16.3.5 → 16.4.1

    これを実行したコマンドは下記。段階的にアップデートして、最後に、GitLabを再起動する。

    sudo apt update
    sudo apt upgrade gitlab-ce=16.3.5-ce.0
    sudo apt upgrade gitlab-ce=16.4.1-ce.0
    sudo gitlab-ctl restart

    何度もやっているので、作業自体はこなれた感じだ。

  • systeminfoは、WindowsXP以降に追加されたコマンド

    タイトルのままだが、systeminfoは、Windows XPから追加されたコマンド。Windows 2000(Windows 2000 Server)には、systeminfoがないので注意。

  • SQL Server エージェントのジョブの権限を与える方法

    SQL Serverで、個別のデータベースに対して、権限を与えても、SQL Server エージェントのジョブの部分はSQL Server Management Studio(SSMS)には、「SQL Server エージェント」も「ジョブ」も表示されない。これの権限は、データベースの権限とは別につける必要がある。

    SQL Serverのジョブ(SQL Server エージェント)に権限を付ける一番簡単な方法は、以下の操作でsysadmin権限の付与を行う。

    1. SSMSを使って、管理者権限のあるユーザでSQL Serverに接続する。
    2. SSMSのオブジェクトエクスプローラーで、「セキュリティ」「サーバー ロール」の順に開く(展開する)。
    3. サーバーロールに表示された「sysadmin」を右クリックして、プロパティを開く。
    4. プロパティの「メンバー」の「追加」をクリックする
    5. 権限を与えるユーザを指定して、OKをクリックする。

    これで権限が付与されるので、権限を与えたユーザで、SSMSで接続して、「SQL Server エージェント」と「ジョブ」が表示されることを確認する。

    もし、SQL Server エージェントだけの権限を与える必要がある場合は、データベースの「msdb」にあるロールを割り当てる。

    1. SSMSを使って、管理者権限のあるユーザでSQL Serverに接続する。
    2. 「セキュリティ」、「ログイン」から、SQL Server エージェントを使わせるユーザのプロパティを開く
    3. 「ユーザーマッピング」を開く。
    4. 「msdb」にチェックをいれ、選択した状態にする
    5. ロールの「SQLAgent~~~」で、最適な権限を選択して、OKをクリックする。

    選択できるロールの概要は以下。

    SQLAgentUserRole
    →SSMSで接続したときに、SQL Serverエージェントが表示される。
     表示されるのは、接続ユーザの権限があるもののみ。

    SQLAgentReaderRole
    →SSMSで接続したときに、SQL Serverエージェントが表示される。
     他のユーザのSQL Serverのジョブも表示される。
     メニューで、ジョブが実行できるように見えるが、実行すると権限がないものはエラーになる。

    SQLAgentOperatorRole
    →SSMSで接続したときに、SQL Serverエージェントが表示される。
     SQL Serverのジョブの表示や実行ができる。

    参考: https://learn.microsoft.com/ja-jp/sql/ssms/agent/sql-server-agent-fixed-database-roles?view=sql-server-ver15

  • Veeam Backup &Replication 11で設定できるイミュータブル期間の最大期間

    Veeam Backup& Replicationで設定できるイミュータブル期間(データの変更を禁止する不変期間)を調べてみた。

    https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110

    バックアップファイルは、構成された期間(最小7日、最大— 9999)の間イミュータブルになります。イミュータビリティ期間は、アクティブなバックアップチェーンに対してのみ延長されます。 バックアップに複数のチェーンがある場合、Veeam Backup & Replicationは、チェーン内の古いバックアップのイミュータビリティを延ばしません。

    https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110

    上記がVeeamのサイトにあるので、イミュータブル期間の最大期間は、9999日。無限にはできない。年にすると、 27.38年になる。

  • SQL Server でストアドプロシージャの一覧を表示する

    SQL Serverでストアドプロシージャの一覧を表示するためには、「INFORMATION_SCHEMA」の「ROUTINES」ビューを参照する。’ROUTINE_TYPE’で’PROCEDURE’ を指定することでプロシージャのみに絞り込める。絞り込みを行わない場合は、FUNCTION なども表示される。

    ■プロシージャのみで絞り込み

    SELECT
        *
    FROM
        INFORMATION_SCHEMA.ROUTINES
    WHERE
        ROUTINE_TYPE = 'PROCEDURE'
    ORDER BY
        SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME

    ■プロシージャだけでなく、ファンクションも表示する

    SELECT
        *
    FROM
        INFORMATION_SCHEMA.ROUTINES
    ORDER BY
        SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME

    ■必要なものだけ表示する

    SELECT
        SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME, ROUTINE_CATALOG, ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
    FROM
        INFORMATION_SCHEMA.ROUTINES
    ORDER BY
        SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME

    参考:

    INFORMATION_SCHEMA.ROUTINES の説明

    現在のデータベースの現在のユーザーがアクセスできるストアド プロシージャと関数ごとに、1 行のデータを返します。 戻り値を記述する列は、関数にのみ適用されます。 ストアド プロシージャの場合、これらの列は NULL になります。

    https://learn.microsoft.com/ja-jp/sql/relational-databases/system-information-schema-views/routines-transact-sql?view=sql-server-ver16

  • Veeam Backup & Replication 11で必要なメモリサイズ

    1台のサーバに、データの保存先を含めたVeeam Backup & Replicatiion 11の全機能をインストールするときに必要なメモリサイズを計算する。同時に実行するタスクの数により、必要なメモリとCPUのコア数が変わる。4タスクを同時に動かす想定。

    4タスクを同時実行する、1台構成のVeeamのメモリとCPU

    ■メモリサイズ

    基本  4GB
    コンソール 0GB(2GB ‐ 2GB)
    プロキシサーバ 6GB(2GB x 4タスク ‐ 2GB)
    バックアップリポジトリサーバ 10GB(4GB + 2GB x 4タスク ‐2GB)
    ※1台に複数機能を入れる場合には、1機能あたり、2GBを引けるとのこと
    ※バックアップリポジトリを分割すると、半分の10GBで済む。その場合は、バックアップリポジトリサーバは、12GBのメモリが必要になる想定。

    合計 20GB

    ■CPUのコア数

    基本 4コア
    プロキシサーバ 4コア(1コア x 4タスク)

    合計 8コア

    ここでの計算が漏れている可能性もあるため、余剰でメモリを割り当てられるのであれば、もっと多いメモリサイズを割り当てた方がよい。

    参考:  https://helpcenter.veeam.com/jp/archive/backup/110/vsphere/system_requirements.html

  • Veeam Backup & Replication 12で必要なメモリサイズ

    1台のサーバに、データの保存先を含めたVeeam Backup & Replicatiion 12の全機能をインストールするときに必要なメモリサイズを計算する。同時に実行するタスクの数により、必要なメモリとCPUのコア数が変わる。4タスクを同時に動かす想定。

    なお、バージョン12では、バックアッププロキシでの複数タスクの実行で消費されるメモリが少なくなっている。

    4タスクを同時実行する、1台構成のVeeamのメモリとCPU

    ■メモリサイズ

    基本  6GB(4GB + 0.5GB x4タスク)
    コンソール 0GB(2GB ‐ 2GB)
    プロキシサーバ 2GB(2GB + 0.5GB x 4タスク ‐ 2GB)
    バックアップリポジトリサーバ 6GB(4GB + 1GB x 4タスク ‐2GB)
    ※1台に複数機能を入れる場合には、1機能あたり、2GBを引けるとのこと
    合計 14GB

    ■CPUのコア数

    基本 4コア
    プロキシサーバ 4コア(1コア x 4タスク)
    合計 8コア

    ここでの計算が漏れている可能性もあるため、余剰でメモリを割り当てられるのであれば、もっと多いメモリサイズを割り当てた方がよい。

    参考: 

    https://helpcenter.veeam.com/docs/backup/vsphere/system_requirements.html?ver=120