I use Azure CLI to created a container in database but it's always through for me an error like this:
[\"The partition key component definition path 'C:\\/Program Files\\/Git\\/zip1' could not be accepted, failed near position '0'. Partition key paths must contain
only valid characters and not contain a trailing slash or wildcard character."]}
My azure cli is like this:
az cosmosdb sql container create --account-name testaccjul1 --resource-group demo-app-test --database-name cosdbjul2 --name container1 --partition-key-path '/zip' --throughput 400
Could anyone tell me where I am wrong? thank you for you help
Please put the partition key path in double quotes. Something like:
az cosmosdb sql container create --account-name testaccjul1 --resource-group demo-app-test --database-name cosdbjul2 --name container1 --partition-key-path "/zip" --throughput 400
This is based off of example here.
Related
According to the picture from this page ceph splits objects on chunks and writes them on osds.
For viewing objects distribution with replication algorithm I can use commands like ceph pg dump or ceph osd map.
But I can't find commands to view data chunk distribution.
You can use the ceph-objectstore-tool to query offline OSDs and see which OSD contains which data chunk:
[ceph: root#pacific /]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1/ --op list
["11.2s2",{"oid":"file","key":"","snapid":-2,"hash":779072666,"max":0,"pool":11,"namespace":"","shard_id":2,"max":0}]
The first entry contains the shard ID: "11.2s2". So the PG is 11.2 and shard ID is 2. To query a cephadm deployed OSD you need to stop it via cephadm and then enter the container:
pacific:~ # cephadm unit stop --name osd.1
Inferring fsid 0a8034bc-15f4-11ec-8330-fa163eed040c
pacific:~ # cephadm shell --name osd.1
Why are some openstack instances found in the "dashboard" and viewed using the command 'nova list --ip [ip]', but not found using the command 'openstack server list|grep [ip]', 'nova list|grep [ip]'?
It is hard to say for sure what the cause of your problem is from the information you provided.
However, nova list and openstack server list both default to listing instances for the current project only. To list instances for all projects, you need to include the --all-tenants or --all-projects option respectively.
Refer to the Nova list command command to select parameter parameters:
--limit
Maximum number of servers to display. If limit == -1, all servers will be displayed. If limit is bigger than 'CONF.api.max_limit' option of Nova API, limit 'CONF.api.max_limit' will be used instead.
We have configured OpenSearch in AWS. We need to send two different application logs to two different indexes in OpenSearch using Fluent Bit. We are using tail as an INPUT and ES as an OUTPUT. Please find below fluent-bit configuration -
INPUT -
[INPUT]
name tail
path /var/log/messages
Refresh_Interval 1
Tag messages
Path_Key On
read_from_head true
[INPUT]
name tail
path /var/log/secure
Refresh_Interval 1
Tag secure
Path_Key On
read_from_head true
OUTPUT -
[OUTPUT]
Name es
Match *
Host opensearch-url
Port 443
HTTP_User admin
HTTP_Passwd ************
tls On
tls.verify Off
Include_Tag_Key On
Tag_Key tag
When I tried to run pgbench, during the initialization phase, ran into an error that “This ALTER TABLE command is not yet supported.” See details below:
$ pgbench -i -U postgres -d postgres -p 5433 -h 127.0.0.1
NOTICE: table "pgbench_branches" does not exist, skipping
WARNING: Storage parameter fillfactor is unsupported, ignoring
NOTICE: table "pgbench_tellers" does not exist, skipping
WARNING: Storage parameter fillfactor is unsupported, ignoring
NOTICE: table "pgbench_accounts" does not exist, skipping
WARNING: Storage parameter fillfactor is unsupported, ignoring
NOTICE: table "pgbench_history" does not exist, skipping
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
**set primary key...
ERROR: This ALTER TABLE command is not yet supported**.
In YugaByte DB, currently, the PRIMARY KEY clause has to be specified as part of the CREATE TABLE statement, and cannot be added after the fact via an ALTER TABLE command.
We have made a recent change to the "pgbench" utility (that's bundled as part of the YugaByte DB distribution) to specify the PRIMARY KEY as part of the CREATE TABLE statement itself.
The relevant issue is:
https://github.com/YugaByte/yugabyte-db/issues/1774
The relevant commit:
https://github.com/YugaByte/yugabyte-db/commit/35b79bc35eede9907d917d72e516350a4f6bd281
I'm trying to setup response headers on my separate webservers that outputs the physical name of the machine that nginx is running on, so that I can tell which servers are serving the responses to our web clients.
Is there a variable that exists to do this already? Or do I just have to hardcode it per-server :(
You're after the $hostname common variable. Common variables are listed in the variable index.
The nginx access log documentation only shows variables that are specific to the access log:
The log format can contain common variables, and variables that exist
only at the time of a log write.
I guess you're looking for $hostname variable.
At first I thought the answer was to use the ENV variable and pull out the hostname from there https://docs.apitools.com/blog/2014/07/02/using-environment-variables-in-nginx-conf.html. But I couldn't get it to work for some reason.
However, this works like a charm:
perl_set $server_int 'sub { use Sys::Hostname; return hostname; }';
And example usage:
add_header 'Server-Int' "$server_int";
Just have to make sure your nginx is compiled with --with-http_perl_module - just run nginx -V to make sure. And that you have Sys::Hostname installed.
Warning: I at first used hostname to return the hostname in the Perl script, but while that did return the name, it for some reason aborted the rest of the output. I don't know if it's a bug with perl_set but you've been warned - using backticks in perl_set may be deadly.