I'm trying run redis/yedis on the yugabyte database by following https://docs.yugabyte.com/latest/yedis/quick-start/#linux.
I run the command ./bin/yb-ctl setup_redis but I end up with the error:
Setting up YugaByte DB support for Redis API.
Waiting for cluster to be ready.
Traceback (most recent call last):
File "./bin/yb-ctl", line 2104, in <module>
control.run()
File "./bin/yb-ctl", line 2081, in run
self.args.func()
File "./bin/yb-ctl", line 1967, in setup_redis_cmd_impl
self.wait_for_cluster_or_raise()
File "./bin/yb-ctl", line 1646, in wait_for_cluster_or_raise
if not self.wait_for_cluster():
File "./bin/yb-ctl", line 1591, in wait_for_cluster
cmd_list_tservers = self.yb_admin_cmd_list("list_all_tablet_servers")
File "./bin/yb-ctl", line 2036, in yb_admin_cmd_list
raise ValueError("Cannot form yb-admin command without knowing master addresses")
ValueError: Cannot form yb-admin command without knowing master addresses
Viewing file /tmp/tmpbg32mn95:
^^^ Encountered errors ^^^
2021-12-22 16:08:27,463 INFO: Waiting for master and tserver processes to come up.
I have my master and tserver both running after running the commands:
./bin/yb-master --flagfile master.conf >& /home/doug/mark/disk1/yb-master.out &
./bin/yb-tserver --flagfile tserver.conf >& /home/doug/mark/yb-tserver.out&
The master config file:
--master_addresses=192.168.1.62:7100
--rpc_bind_addresses=192.168.1.62:7100
--fs_data_dirs=/home/doug/mark/disk1
The tserver config file:
--tserver_master_addrs=192.168.1.62:7100
--rpc_bind_addresses=192.168.1.62:9100
--start_pgsql_proxy
--pgsql_proxy_bind_address=192.168.1.62:5433
--cql_proxy_bind_address=192.168.1.62:9042
--fs_data_dirs=/home/doug/mark/disk1
and in the master log I can see:
I1223 00:08:03.023463 1527298 heartbeater.cc:340] P 419a60d5690945c8ad23c42f7ba758ba: Connected to a leader master server at 192.168.1.62:7100
I1223 00:08:03.023666 1527298 heartbeater.cc:388] P 419a60d5690945c8ad23c42f7ba758ba: Registering TS with master...
But I'm not sure why I can't start up the redis-cli based on the tutorial link above?
Since you're running the yb-tserver & yb-master manually, try running this command:
./bin/yb-admin [-master_addresses server1:port,server2:port,server3:port,...] setup_redis_table
Note that YEDIS API is not a focus, it must be viewed as a deprecated API for new application development purposes. (docs link)
Related
I am able to restore the Odoo database on one of our cloud Ubuntu instances. But while referring to that application in Odoo Conf file, we are getting the below error. Same database is working fine in local environment
File "/usr/lib/python3.8/socketserver.py", line 466, in server_bind
self.socket.bind(self.server_address)
OSError: [Errno 98] Address already in use
2021-03-02 19:16:03,134 7351 ERROR ? odoo.sql_db: bad query: CREATE SEQUENCE base_registry_signaling INCREMENT BY 1 START WITH 1
ERROR: relation "base_registry_signaling" already exists
2021-03-02 19:16:03,278 7351 ERROR ? odoo.modules.registry: Failed to load registry
2021-03-02 19:16:03,281 7351 CRITICAL ? odoo.service.server: Failed to initialize database databasename.
Traceback (most recent call last):
File "/home/odoo2/odoo-12/odoo/service/server.py", line 1162, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo2/odoo-12/odoo/modules/registry.py", line 83, in new
registry.setup_signaling()
File "/home/odoo2/odoo-12/odoo/modules/registry.py", line 378, in setup_signaling
cr.execute("CREATE SEQUENCE base_registry_signaling INCREMENT BY 1 START WITH 1")
File "/home/odoo2/odoo-12/odoo/sql_db.py", line 148, in wrapper
return f(self, *args, **kwargs)
File "/home/odoo2/odoo-12/odoo/sql_db.py", line 225, in execute
res = self._obj.execute(query, params)
psycopg2.errors.DuplicateTable: relation "base_registry_signaling" already exists
I just stumbled on the same problem.
Turns out I dumped the db with the --no-owner option and on import it set the owner to the current user - which was different.
Try setting the owner of the db and tables to the user your're using for odoo.
ALTER DATABASE "db_name" OWNER TO user;
-- Assign everything in the currently selected db to 'user'.
REASSIGN OWNED BY other_user TO user;
you also using a command line to restore odoo database in any verison:
curl -F 'master_pwd=superadmin_passwd' -F backup_file=#/opt/odoo/odoo_backups/db1.2018-04-14.zip -F 'copy=true' -F 'name=db3' http://localhost:8069/web/database/restore
Use above command you using restore your odoo database:
Example like :
curl -F 'master_pwd=admin1' -F backup_file=#/home/dell/backup_dir/back_up_filename.zip -F 'copy=true' -F 'name=db3' http://localhost:8069/web/database/restore
In the example above our the Master Password is ADMIN_PASSWORD and we are creating a backup file back_up_filename.zip of a database named DB_NAME which will be saved in the backup_dir directory.
Note: Depending on the database size and your Internet speed, the restoration process may take some time.
I'm using WebLogic 10.3.6 (it's old, I know) with Java6 and am trying to install in a new environment. I'm using WLST scripts that worked in other environments where the OS is the same (CentOS 5.11), SELinux is in permissive mode, and the application user has permission to write to the directory where all of the WLS stuff is saved. Each time I try to update anything in the SecurityConfiguration MBean, it get a timeout when trying to activate. Initially I thought it was just for the node manager credentials, but I tried to do
!> cmo.setClearTextCredentialAccessEnabled(true)
!> validate()
!> save()
!> activate()
Everything is fine until the activate... here's my results:
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released
once the activation is completed.
Traceback (innermost last):
File "<console>", line 1, in ?
File "<iostream>", line 376, in activate
File "<iostream>", line 1847, in raiseWLSTException
WLSTException: Error occured while performing activate : Error while Activating changes. : [DeploymentService:290053]Request with id '1,488,512,657,383' timed out on admin server.
Use dumpStack() to view the full stacktrace
What am I missing?
The real issue causing this problem was the NFS where my binaries were being shared across instances. The NFS was configured in a VERY non-standard way, causing all kinds of file read/write timeouts.
I try to restore my backup from amazon using the following command as example
duplicity restore --sign-key '7F73FA36' --encrypt-key '5FD0100F' scp://rich#backup_server//mnt/backups/edge/main
and shell returns the following error
"Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Traceback (most recent call last):
File "/usr/bin/duplicity", line 1466, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1459, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1312, in main"
Any advice will greatly help.
If you do not want to store backups in Dropbox, i suppose that this can be ignored.
I wondered the same as you, and looked a bit: it seems to me that Duplicity tries to load a Dropbox backend. See in /usr/lib64/python2.6/site-packages/duplicity/backends/dpbxbackend.py, there is a line from dropbox import client, rest, session
As i do not have this Python Dropbox library installed, it can not find it, but does not prevent me to use Duplicity for other backends
You may install dropbox python client by running
root#host# pip install dropbox2
I get a weird error in my log-files when I start a Zope instance. The instance is running with a ZEO server and the Zope installation is a virtualenv (in /home/myUser/opt). I get this error with several Products, but Zope is working fine and these products are installed. Here is an example with the product BTreeFolder2:
2014-01-22T12:38:13 ERROR Application Couldn't install BTreeFolder2
Traceback (most recent call last):
File "/home/myUser/opt/Zope2-2.13.21/local/lib/python2.7/site-packages/Zope2-2.13.21-py2.7.egg/OFS/Application.py", line 693, in install_product
transaction.commit()
File "/home/myUser/opt/Zope2-2.13.21/local/lib/python2.7/site-packages/transaction-1.1.1-py2.7.egg/transaction/_manager.py", line 89, in commit
return self.get().commit()
File "/home/myUser/opt/Zope2-2.13.21/local/lib/python2.7/site-packages/transaction-1.1.1-py2.7.egg/transaction/_transaction.py", line 329, in commit
self._commitResources()
File "/home/myUser/opt/Zope2-2.13.21/local/lib/python2.7/site-packages/transaction-1.1.1-py2.7.egg/transaction/_transaction.py", line 446, in _commitResources
rm.tpc_vote(self)
File "/home/myUser/opt/Zope2-2.13.21/local/lib/python2.7/site-packages/ZODB3-3.10.5-py2.7-linux-x86_64.egg/ZODB/Connection.py", line 781, in tpc_vote
s = vote(transaction)
File "/home/myUser/opt/Zope2-2.13.21/local/lib/python2.7/site-packages/ZODB3-3.10.5-py2.7-linux-x86_64.egg/ZEO/ClientStorage.py", line 1098, in tpc_vote
return self._check_serials()
File "/home/myUser/opt/Zope2-2.13.21/local/lib/python2.7/site-packages/ZODB3-3.10.5-py2.7-linux-x86_64.egg/ZEO/ClientStorage.py", line 929, in _check_serials
raise s
ConflictError: database conflict error (oid 0x01, class OFS.Application.Application, serial this txn started with 0x03a449da3a7b1e44 2014-01-22 11:38:13.706468, serial currently committed 0x03a449da3af74dee 2014-01-22 11:38:13.820164)
I'd like to fix this, even if it does not affect the functionality of my site, but I don't know where to look. Any suggestions? :)
Or does this just mean that the cached objects have to be renewed with the data of the ZEO server?
When a Zope instances starts up, it registers extensions (Products) in the ZODB. When you run multiple instances sharing a ZEO server, however, and they all start up roughly the same time, you run into conflicts during this stage. The conflicts are essentially harmless, they only occur because another instance did succeed in installing the persistent components.
The solution is to configure instances not to register products, except for one (usually one per machine in a multi-machine cluster); then on restart, only one of the instances does the registration, the rest, running the same software stack, won't have to.
Note that in more recent Zope installations, the persistent parts for Products have been deprecated and mostly disabled; if you don't use Through-The-Web products or ZClasses, you probably don't need to enable this at all.
When you do need it, set the enable-product-installation configuration in zope.conf to on for just one instance, off for the rest. If you use buildout, and the plone.recipe.zope2instance recipe, you can specify this setting in the buildout recipe configuration.
We have an auto-deployment script that uses wsadmin and jython. The script appears to work as expected however after 6-7 redeployments the AdminTask object becomes unavilable, resulting in the following error when we attempt to use that object:
WASX7209I: Connected to process "server1" on node ukdlniqa41Node01 using SOAP connector; The type of process is: UnManagedProcess
WASX8011W: AdminTask object is not available.
...
Traceback (innermost last):
File "<string>", line 251, in ?
File "<string>", line 14, in main
File "<string>", line 38, in initialize
NameError: AdminTask
My question is, what would cause this AdminTask object to become unavailable? (it remains unavailable until we restart the server instance)
AdminTask may be available if one of the previous tasks does not finish properly. This happens often especially if your server is in development mode. I would suggest gathering Deployment Mustgather as per http://www-01.ibm.com/support/docview.wss?rs=180&context=SSCR4XA&q1=MustGatherDocument&uid=swg21199344&loc=en_US&cs=utf-8&lang=en and submitting the results to IBM.